Description of problem: emacs-24.4 adds extra spaces/formatting when copy/pasting text with leading spaces Version-Release number of selected component (if applicable): emacs-24.4-2.fc21.x86_64 How reproducible: Always Steps to Reproduce: 1. start 'emacs -nw foo.txt' 2. copy/paste some multi-line text with spaces in front of some lines - for eg - the following text from my terminal: $ wc gmakefile makefile 213 833 8681 gmakefile 556 2956 28521 makefile 769 3789 37202 total Actual results: emacs formats the text in the following way. $ wc gmakefile makefile 213 833 8681 gmakefile 556 2956 28521 makefile 769 3789 37202 total Expected results: no extra spaces/formatting by emacs. i.e $ wc gmakefile makefile 213 833 8681 gmakefile 556 2956 28521 makefile 769 3789 37202 total Additional info: No such issue existed with emacs-24.3-27.fc21.x86_64
Confirmed, but just for the -nw/--no-window-system mode.
Yes reproduced easily. I want to add same note (as described in this bug) here that that if you have say 3 lines starting from column 0 and you copy them and paste again in front of any one of these lines then there is no issues. The issue arises when in a copied text any single line starts from non-zero column.
Do you have any settings in your .emacs or .emacs.d file? Like (setq-default tab-width 4) or (setq tab-width 4) (setq tab-stop-list '(4 8)) (setq indent-tabs-mode nil)
Hmm, I have reproduced the problem too and I do not have any .emacs file. I am gonna to report the problem to upstream.
Upstream bug report: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19093
Feature? ok. I'll just disable electric-indent-mode in my .emacs (electric-indent-mode 0)
Upstream would like to no how did you do "copy/paste" and what terminal do you used during the action. Any hint?
Upstream did the change in 24.5 http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=bfc3079 I can try to backported. But testers are welcome.
(In reply to Petr Hracek from comment #7) > Upstream would like to no how did you do "copy/paste" and what terminal do > you used during the action. > Any hint? $ echo $TERM xterm - login to gnome3 [on Fedora 21] - start 2 gnome-terminals - run "emacs -Q -nw foo.txt" in gnome-terminal-1 - run 'wc makefile gmakefile' in gnome-terminal-2 - copy text from gnome-terminal-2 using mouse [click - drag] - paste text into gnome-terminal-1 [with emacs] using mouse middle-button. Also - I see the same issue - if I use xterms - instead of gnome-terminals. Note: my primary use case here is - I run "emacs -nw" as my e-mail editor [from alpine] - so I end up doing such copy/paste frequently. (In reply to Petr Hracek from comment #8) > Upstream did the change in 24.5 > http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=bfc3079 > > I can try to backported. > But testers are welcome. Sure - I can test [either from updates-testing - or a koji scratch build..] Or you could consider defaulting 24.4 to use (electric-indent-mode 0). Presumably that was the default for 24.3?
I built emacs from git [both master branch - and emacs-24 branch with bfc3079 cherry picked] with options: --with-x-toolkit=no --with-xpm=no --with-gif=no Both builds do not exhibit this copy paste issue.
Hi Satin, scratch build with backported patch is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=9136901 Could you please verify it? Greetings Petr
I don't see this problem with the scratch build. Will continue to use it and see how it goes.
Now I see 'Ctrl-S' search - with a copy/paste string is misbehaving. 1. Ctrl-S 2. copy/paste some text to search. 3. Its inserted into the buffer - instead of into the 'search'/message bar I've reverted back to emacs-24.4-3 with (electric-indent-mode 0)
This should be solved in next emacs version 24.5. If not please reopen bug again.
Here are my observations: emacs-24.4-6.fc21.x86_64 (default) - copy/paste spaces: fixed - ctrl-s paste: broken emacs-24.4-6.fc21.x86_64 (electric-indent-mode 0) - copy/paste spaces: fixed - ctrl-s paste: broken [i.e the patch fixed 'copy/paste spaces' broke 'ctrl-s paste'] emacs-24.5-1.fc21.x86_64 (default) - copy/paste spaces: broken - ctrl-s paste: fixed emacs-24.5-1.fc21.x86_64 (electric-indent-mode 0) - copy/paste spaces: fixed - ctrl-s paste: fixed [i.e this was the state when I initially reported this issue with emacs-24.4-2.fc21.x86_64 - so the patch didn't get into emacs-24.5-1.fc21.x86_64?] I'm happy enough with the current state [where both modes work with the option (electric-indent-mode 0) - so I'll leave this issue closed.
Not only does this happen when copy/pasting stuff, but also when getting Emacs to auto-complete code for you. Very annoying default behaviour. See my post in http://emacs.stackexchange.com/questions/10896/avoid-extra-tabs-when-generating-haskell-code-with-ghc-mod
(In reply to Satish Balay from comment #15) > Here are my observations: > > emacs-24.4-6.fc21.x86_64 (default) > - copy/paste spaces: fixed > - ctrl-s paste: broken > > emacs-24.4-6.fc21.x86_64 (electric-indent-mode 0) > - copy/paste spaces: fixed > - ctrl-s paste: broken > > [i.e the patch fixed 'copy/paste spaces' broke 'ctrl-s paste'] > > emacs-24.5-1.fc21.x86_64 (default) > - copy/paste spaces: broken > - ctrl-s paste: fixed > > emacs-24.5-1.fc21.x86_64 (electric-indent-mode 0) > - copy/paste spaces: fixed > - ctrl-s paste: fixed > > [i.e this was the state when I initially reported this issue with > emacs-24.4-2.fc21.x86_64 - so the patch didn't get into > emacs-24.5-1.fc21.x86_64?] > > I'm happy enough with the current state [where both modes work with the > option (electric-indent-mode 0) - so I'll leave this issue closed. Looks like this patch got its way into emacs-25.0.93-2.fc24.x86_64 and I see the broken 'ctrl-s' paste behavior. Refiled the issue at: https://bugzilla.redhat.com/show_bug.cgi?id=1335247