paste adds extra characters on Gnome Terminal

[dparsons]

This ticket follows up Debian bug #734571 [1].

Paste in mc is failing on Gnome Terminal by adding extra characters at front and
back of the desired string. e.g. copying (highlighting) the "/.."
string from the mc list of files and directories gets pasted (middle
mouse button or Ctrl-Shift-V) as "^[[200~/..^[[201~"

The failure does not happen immediately. As far as I can tell it
occurs after maximising the window and toggling between the file
display and the plain command line using Ctrl-o. Both those steps
seem to be necessary to reproduce the bug. After that, all pastes within the terminal fail in this way.

I experience the bug running mc in Gnome Terminal
(multiple versions, currently Gnome 3.12). Apparently only Gnome Terminal is affected, not other terminals.

The bug seems to have been triggered by Changeset c55b48 [2], created for MC ticket #2661 [3] (thank you to Yury V. Zaytsev for finding that). When I revert that commit from current git, the bug disappears.

Is it a bug in Gnome Terminal or should a fix be applied in mc on top of commit c55b48?

[1] ​https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734571
[2] ​http://www.midnight-commander.org/changeset/c55b4808f69b98338e7ce55e2595b7471391abbc
[3] ​http://www.midnight-commander.org/ticket/2661

$ mc -V
GNU Midnight Commander 4.8.12
Built with GLib 2.38.2
Using the S-Lang library with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ext2undelfs, ftpfs, sftpfs, fish
Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

[egmont]

I'm using gnome-terminal 3.12 and mc 4.8.12 all the time, yet I haven't faced this bug and can't reproduce now (trying Ctrl+O and maximizing the terminal randomly).

Could you please give an _exact_ list of steps that triggers the bug for you? (Please mention every single keypress, mouse click, resize etc. from the moment you start mc.)

Please make sure that copy-pasting works as expected at your shell prompt before you start mc. It could be that a previously crashing appliction leaves the terminal in that "bracketed paste mode" where it emits those ^[[200~/^[[201~ things.

[egmont]

I see in the downstream bugreport that you've tried with vanilla mc (i.e. guaranteed to have no Debian-specific patches). I'm not sure how to check if VTE (the core of gnome-terminal) has such a patch that could break it.

Could you please download ​ftp://ftp.gnome.org/pub/GNOME/sources/vte/0.36/vte-0.36.1.tar.xz, compile with ./configure && make, and run (without installation) with ./src/vte2_90 and then run mc inside this terminal? Ctrl+Shift+C/V won't work, but you can highlight and then paste Shift+Insert. Is it buggy there for you?

This is just to double check that the bug is not caused by a debian-specific change in VTE.

[dparsons]

That's weird that you're not experiencing the bug. You'd have already noticed by now if it was affecting you! That suggests it must be a Debian patch in VTE.

I can reproduce it precisely this way:

1) start gnome-terminal
2) start mc in that terminal
3) enter the Ctrl-o subshell
4) maximise the terminal
5) leave the Ctrl-o subshell (i.e. return to the dir/file list)
6) copy some text (e.g. some "filename")
7) return back to the Ctrl-o subshell
8) paste the text
The text is pasted as "0~filename1~" instead of "filename" and the warning bell is triggered

Alternatively, using cat

1) start gnome-terminal
2) start mc in that terminal
3) run cat from the mc command line (in normal file view) [which of course starts a subshell]
4) maximise the terminal
5) leave the Ctrl-o subshell (i.e. return to the dir/file list)
6) copy some text (e.g. some "filename")
7) return back to the Ctrl-o subshell
8) paste the text

The subshell then shows:

$ cat
^[[200~filename^[[201~
[200~filename[201~

(with no warning bell. I presume ^[[20 represents the warning bell).

[egmont]

Okay, I can reproduce. (I always tried pasting with the panels on.)

I'll take a look. Probably both vte and mc will receive a patch. I mean, obviously gnome-terminal/vte is doing something differently than xterm which is not good, yet mc should also work correctly with current vte.

[dparsons]

Yeah, I also reproduced the bug using vte2-90 directly building from the upstream tarball you linked to. Not a Debian patch-bug apparently.

Incidentally, the Debian patches are located at ​http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/vte3/debian/ (in the patches subdir).

Thanks for looking into it!

[egmont]

VTE bugreport and fix: ​https://bugzilla.gnome.org/show_bug.cgi?id=729533

[egmont]

The ncurses build doesn't suffer from the bug.

The output of mc consists of both tons of ^{[[?47h/l (explicit in do_{enter,exit}_ca_mode) and tons of the almost equivalent} [[?1049h/l (probably implicit in some ncurses/slang method), in a weird order that's different in slang than in ncurses, plus some extra ones of these on resize. So far they don't make too much sense to me. And of course these are intertwining with ^{[[2004h/l ones (the ones that enable/disable bracketed mode)... It won't be easy to come up with a clean, non-hacky solution.}

Anyway, there's a clean fix for VTE in the mean time. Maybe that one on its own is good enough??

[dparsons]

That vte patch fixes the behaviour for me.

[egmont]

Terminology (Enlightenment) suffers from the same bug, reported here: ​https://phab.enlightenment.org/T1233

I haven't had time to look at MC yet, but I more and more tend to agree with Dmitry in the Debian thread who said "If problem is in gnome terminal I'm not going to suggest upstream developers to introduce workaround that no other terminal emulator needs". It would be nice if MC provided a workaround, but this should be fixed in terminals in the first place.

[dparsons]

I agree, it sounds like fixing the problem in the terminals is the neatest solution.

[egmont]

As such, I've changed it to a low priority enhancement request to work around broken terminal emulators.

[egmont]

VTE 0.36.2 (Gnome 3.12.2) fixes the bug.
Terminology git (post-0.5) fixes the bug.

[egmont]

It seems I won't spend time on a workaround for broken terminal emualtors, and probably nobody will. The effected terminal emulators are fixed now and this should be good enough.

Could someone please close this bug?

[dparsons]

Your patch for Gnome Terminal (vte) has been working well. Thanks for catching the fix for terminology too. You've done a great job. I'm happy for the bug to be closed now, though I don't have the permissions to close it myself.

[andrew_b]

Thanks everyone!

Closed as 'invalid' since it is not bug in mc.

[zaytsev]

For Trusty see the following bug:

​https://bugs.launchpad.net/ubuntu/+source/vte3/+bug/1506166

[andrew_b]

Ticket #3645 has been marked as a duplicate of this ticket.