Ticket #3207 (closed enhancement: invalid)
paste adds extra characters on Gnome Terminal
Reported by: | dparsons | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | mc-tty | Version: | master |
Keywords: | paste | Cc: | egmont, onlyjob@… |
Blocked By: | Blocking: | ||
Branch state: | no branch | Votes for changeset: |
Description
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;
Change History
comment:3 Changed 10 years ago by 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.
comment:4 Changed 10 years ago by 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.
comment:5 Changed 10 years ago by 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).
comment:6 Changed 10 years ago by 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.
comment:7 Changed 10 years ago by 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!
comment:8 Changed 10 years ago by egmont
VTE bugreport and fix: https://bugzilla.gnome.org/show_bug.cgi?id=729533
comment:9 Changed 10 years ago by 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??
comment:11 Changed 10 years ago by dparsons
That vte patch fixes the behaviour for me.
comment:12 Changed 10 years ago by 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.
comment:13 Changed 10 years ago by dparsons
I agree, it sounds like fixing the problem in the terminals is the neatest solution.
comment:14 Changed 10 years ago by egmont
- Priority changed from major to minor
- Type changed from defect to enhancement
As such, I've changed it to a low priority enhancement request to work around broken terminal emulators.
comment:15 Changed 10 years ago by egmont
VTE 0.36.2 (Gnome 3.12.2) fixes the bug.
Terminology git (post-0.5) fixes the bug.
comment:16 Changed 10 years ago by 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?
comment:17 Changed 10 years ago by 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.
comment:18 Changed 10 years ago by andrew_b
- Status changed from new to closed
- Resolution set to invalid
- Milestone Future Releases deleted
Thanks everyone!
Closed as 'invalid' since it is not bug in mc.
comment:19 Changed 9 years ago by zaytsev
For Trusty see the following bug:
https://bugs.launchpad.net/ubuntu/+source/vte3/+bug/1506166
comment:20 Changed 8 years ago by andrew_b
Ticket #3645 has been marked as a duplicate of this ticket.