Bug 1161786

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