GNOME Bugzilla – Bug 123844
Select after copy overwrites clipboard contents
Last modified: 2009-11-27 18:40:33 UTC
It would be really useful if there was an option to turn off the *feature* that everything you highlight by mouse is automatically copied to clipboard. I prefer to choose Copy in the context menu myself, that's the more common way to do it on the desktop... And losing what you have copied on your clipboard, just because you pressed the mouse button is annoying.
Please see http://freedesktop.org/Standards/clipboards-spec The selection is not the clipboard and has nothing to do with it. Unfortunately, many applications, application authors, and users are confused about this point. Just ignore the whole middle-click thing.
What I do: open a gnome-terminal, open an epiphany. Select some text in gnome-terminal, go to address bar in epiphany, right click and select paste, and I see what I selected in gnome-terminal. So, either I cannot understand your comment, or it is a bug.
Oops, I shouldn't have changed the bug status. Sorry.
To reproduce: 1. open gnome-terminal (mine is 2.4.0.1 HEAD) 2. Type 'echo http://www.example.com' and press Enter. 3. Highlight the resultant 'http://www.example.com' (i.e., by double-clicking). Right-click on it and select 'Copy' (NOT 'Copy Link Address'). 4. Open gedit (open ANYTHING, really -- we just want somewhere to paste text) 5. Right-click in gedit, click 'paste'. It will paste 'http://www.example.com' 6. Empty the gedit file 7. Double-click on the word 'echo' in the open gnome-terminal 8. Right-click in the gedit window and click 'paste' Result: 'echo' is pasted, not 'http://www.example.com' 9. Open up a new gnome-terminal (close the other if you wish) 10. Select any text in it 11. Try pasting it in gedit Result: the bug is gone! It'll still paste 'echo' because that's what's in the clipboard.
So the bug is there. NO??
So here is the real bug: If you select AND copy something in the gnome-terminal, then selecting any other text in THAT terminal after that would replace the text in clipboard.
I see, thanks. Sounds broken.
Retitling.
*** Bug 162962 has been marked as a duplicate of this bug. ***
Adding some info to this bug.. ..recompiled vte with --enable-debugging and trying to reproduce (adding a couple of debug statements in vte_terminal_{copy,paste} to see which clipboard we're working with) michele@kantele:/home/devel/gnome/cvs/gnome-terminal/src$ export VTE_DEBUG_FLAGS=selection,io michele@kantele:/home/devel/gnome/cvs/gnome-terminal/src$ libtool --mode=execute ./gnome-terminal --disable-factory Set terminal encoding to `UTF-8'. <snip> Wrote f Wrote o Wrote o <snip selection calls> Selection changed to (58,0) to (60,0). clipboard for the copy is PRIMARY (1) Assuming ownership of selection. -----------> <until here I just selected "foo" and clipboard is correctly set to PRIMARY> Copying to CLIPBOARD. clipboard for the copy is CLIPBOARD (69) Assuming ownership of selection. -----------> <here I pressed Ctrl-shift-C> Pasting CLIPBOARD. Requesting clipboard contents. clipboard for paste is CLIPBOARD (69) Setting selection (3 UTF-8 bytes.) 0x0066 0x006f 0x006f Pasting 3 UTF-8 bytes. Wrote f Wrote o Wrote o -----------> <and here I pressed Ctrl-shift-V> -----------> <now I type in 'bar'> Wrote b Wrote a Wrote r -----------> <and I select 'bar'> Deselecting all text. <snip all the selection resize stuff> Selection changed to (58,1) to (60,1). clipboard for the copy is PRIMARY (1) Assuming ownership of selection. -----------> <clipboard correctly set to PRIMARY> -----------> <now I press Ctrl-shift-V and I correctly obtain the pasting of CLIPBOARD and not PRIMARY> Pasting CLIPBOARD. Requesting clipboard contents. -----------> <and here is the bug..."bar" get's pasted which should only be on PRIMARY, instead of "foo" which should be the one on CLIPBOARD> Setting selection (3 UTF-8 bytes.) 0x0062 0x0061 0x007 Pasting 3 UTF-8 bytes. Wrote b Wrote a Wrote r <snip the rest>
*** Bug 121758 has been marked as a duplicate of this bug. ***
*** Bug 143544 has been marked as a duplicate of this bug. ***
Here's Mariano's explanation (in #143544) for reference: """ This is due to the fact that vte terminals have only one pvt->selection: if I select some text, and do an explicit copy, the text gets copied into terminal->pvt->selection and vte_terminal_copy_cb will take it from there when the selection gets requested. But if now I select something else but without an explicit copy, vte_terminal_button_release will call vte_terminal_copy(terminal, GDK_SELECTION_PRIMARY) which will overwrite terminal->pvt->selection, so that if vte_terminal_copy_cb gets called now in a request for the CLIPBOARD, it'll send the PRIMARY... (If you run xclipboard while you do all this, you won't see this, because it'll be getting the CLIPBOARD so that when you get it you don't get it from terminal->pvt->selection but from it's own cache) Not terribly hard to fix, I guess... """
Created attachment 51069 [details] [review] My proposed solution - don't use callbacks for clipboard selection AFAICS, the only reason for using selection callbacks is to clear the highlighting when the selection changes. But IMO this should only happen when the PRIMARY selection changes. So this patch fixes this bug by not using callbacks for the CLIPBOARD selection.
Created attachment 58560 [details] [review] committed patch. I believe I fixed this.
I am using vte 0.11.18, which contains the patch provided by Behdad, and Gnome Terminal 2.10.0. Thanks for the fix, but now how I can paste PRIMARY selection without using the mouse (middle-click)? Shift+Insert pastes CLIPBOARD selection. I think Shift+Insert should paste PRIMARY selection, like other terminal emulators do, and CLIPBOARD selection should be pasted by using Shift+Ctrl+V, when using only keyboard shortcuts.
The Shift+Insert behavior is consistent with all other GNOME apps. I'm going to make Ctrl+Shift+Insert paste PRIMARY. How's that?
2006-02-13 Behdad Esfahbod <behdad@gnome.org> * src/vte.c (vte_terminal_key_press): Handle Ctrl+Shift+Insert to paste PRIMARY.
According to Nalin (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181418) inserting PRIMARY on Shift-Insert may have been inconsistent with other gnome apps, but it was consistent with xterm, which is a somewhat relevant axis of compatibility for an X terminal emulator.
I read in another bug (cannot find) that Nalin said if the consistency with other GNOME apps is desired, gnome-terminal can override shift+insert, but vte should be consistent with xterm and paste PRIMARY on shift+insert. I don't mind making it like that, but that doesn't solve the redhat bug, g-t would still paste CLIPBOARD. xterm pastes PRIMARY because it doesn't handle CLIPBOARD at all (or does it?) Anyway, today I added ctrl+shift+insert to paste PRIMARY. Is that enough? Note that previously it was a mess and it was not quite clear what shift+insert does, since it was mixing PRIMARY and CLIPBOARD.
I see no reason why we should unexpectedly and unintuitively paste PRIMARY with shift+insert if throughout GNOME CLIPBOARD is pasted with that combination (consistency) and if xterm is from the era where all the different clipboards in X weren't consistently used, and xterm probably simply didn't know a thing about the convention (in the modern days) of PRIMARY. Remember the mess with clipboards across KDE and GNOME for example, perhaps? If PRIMARY should have a keybinding at all, then an extra modifier like ctrl sounds good to me. I've always found weird that shift+insert gives me something really unexpected.
gnome-terminal has pretty consistently leaned more toward being a terminal emulator than the poster child for the perfect GNOME app (for example, the default keyboard copy/cut keybindings are Ctrl+Shift+C/X rather than the usual Ctrl-C/X, because you really want to be able to press Ctrl-C). I think the original reasoning (pure conjecture, of course) was that the group of people who use terminal emulators heavily expect them to behave like traditional terminal emulators (which, really, are a throwback to actual terminals, where this stuff doesn't just change).
I see dups coming... Maybe I should switch the two... That's really weird though. If you have selected something using mouse, you may as well use mouse to paste it. If you have selected using keyboard, you may as well copy it too. So I don't see why pasting PRIMARY is that useful.
*** Bug 331152 has been marked as a duplicate of this bug. ***
(In reply to comment #23) > I see dups coming... Maybe I should switch the two... I can't comment much here since I don't have much training with shift-insert. > That's really weird though. If you have selected something using mouse, you > may as well use mouse to paste it. If you have selected using keyboard, you > may as well copy it too. So I don't see why pasting PRIMARY is that useful. I do have some comments here though. Personally, I want to use the keyboard for everything. But in some situations I don't know of a way to do a keyboard-based select[*]. So, if I'm 'forced' to do a mouse-based selection like this, I still prefer to go back to the keyboard for the pasting piece. Then, as far as PRIMARY vs. CLIPBOARD, I often use PRIMARY with the mouse because it's just plain fewer operations, (select rather than select+copy). If I could get that same operation with a keyboard, then I would be happy to use keyboard-based PRIMARY as well. [*] gnome-terminal being the primary offender here. Is there any support for keyboard-based selection that I'm not aware of? Does anybody know of any existing efforts to provide it?
Ok, that's almost what my usecases are too. But I mostly want to just copy URLs from Firefox, and so can use keyboard. And it was very annoying that I had to switch to Firefox, move the cursor such that the selection goes away, and press ctlr+A to select the URL (with copying to PRIMARY this time) again, and come back paste it. On the other hand, copy/paste using ctrl+insert / shift+insert is really faster in this particular situation... As for keyboard selection in g-t, no idea. I had this idea of having a search functionality in g-t, probably going in reverse direction by default. That can be combined with a keyboard selection mode.
(In reply to comment #26) > Ok, that's almost what my usecases are too. But I mostly want to just copy > URLs from Firefox, and so can use keyboard. OK. > And it was very annoying that I > had to switch to Firefox, move the cursor such that the selection goes away, > and press ctlr+A to select the URL (with copying to PRIMARY this time) again, > and come back paste it. On the other hand, copy/paste using ctrl+insert / > shift+insert is really faster in this particular situation... I'm definitely missing some context here. What is ctrl+insert ? And ctrl+insert/shift+insert is faster than what exactly? (It doesn't make it easy that the semantics of "shift+insert" are overloaded with two different meanings in this context.) So far, in my experiments I've had good success using keyboard-based selection in firefox to set PRIMARY. And this is the 'efficient' means I described before where I can do selection alone, without an explicit copy operation. Oh, I guess you were referring to the situation when switching to firefox, it already has the text selected, but that text is not in PRIMARY? Oh, what do you know, ctrl-insert is handy in that situation. I never realized that before. Personally, though, I don't think I would ever use that myself. The whole reason I like to use PRIMARY is that there is no explicit "copy" operation needed, (in most cases there's no need for ctrl-insert). In the cases where an explicit copy operation is needed, then CLIPBOARD seems like a fine thing for me. That way I only have to use/remember one keybinding for "copying".
I feel compelled to add my two cents to this one.... Shift-insert has long standing as a way to paste primary into terminals. vte -- and even gnome-terminal -- should not change that. No matter what other gnome or gtk apps do. Control-insert is the norm for pasting clipboard. Not everyone using gnome-terminal runs gnome per se, and certainly not everyone who uses vte. What is boils down to is that being different from the rest of the term pack is much worse here than being different from the rest of the gnome pack.
Your arguments do not make much sense. 1) Ctrl+Insert is consistently used to *copy* clipboard, and shift+insert used to paste it. 2) gnome-terminal is the official terminal emulator of the GNOME desktop, so I see it a far higher priority to be consistent with the GNOME apps, instead of parallel software. In other words, why should gedit be consistent with kate and notepad?? 3) If other distributions/desktops/whatever use vte or gnome-terminal, fine, they should patch it to suite their needs.
I think there should at least be a (gconf?) option for the 'old' behaviour to come back. I don't want to change back to xterm (UTF-8 hell; font hell) or switch to konsole (KDE fingerprint!) just because of a simple key binding! All other terminal emulators in X that I've seen use shift+insert ot paste PRIMARY. Yes, Gnome should be consistent, but can you imagine how people are going to see this change ('see! they removed another useful option! gnome is evil!')
Yes, please make it configurable. Gnome-terminal should atleast give you the option to make it the same as all other terms or gnome specific. I can understand some if you find the original shift-insert confusing but I for one can stand the new standard. Oh, and also: See! They removed another useful option! Gnome is Evil! :-)
No configuration. Any idea how to make a decision? I actually don't mind switching the current behavior of shift+insert and ctrl+shift+insert. Will everyone be happy that way?
I would label it as a quirk, and learn to live with having to hold down control too, over time. If we are to really do it, I think it should be at least documented somewhere in the help/docs.
Ok, I made shift+insert paste PRIMARY and ctrl+shift+insert paste CLIPBOARD.
(In reply to comment #32) > No configuration. I don't understand. gnome-terminal already provides Edit->"Keyboard shortcuts". Is there a plan to get rid of all of that? > Any idea how to make a decision? I actually don't mind switching the current > behavior of shift+insert and ctrl+shift+insert. Will everyone be happy that > way? I'm still not sure what "current" means. I can try a version of gnome-terminal that I have running here, but I suspect the behavior may have changed once or twice since then. [This is a general problem I've often seen in trying to make sense of old bugzilla traffic. Descriptions of software behavior with time-sensitive references "now", "before", etc. end up being rather meaningless.] -Carl
(In reply to comment #34) > Ok, I made shift+insert paste PRIMARY and ctrl+shift+insert paste CLIPBOARD. [I should have read through to this point before my previous comment.] Thank you for the above wording. This is accurate and useful even to someone who reads this bug traffic historically. Much better than something like "OK, I switched shift+insert and ctrl+shift+insert" for example. So, pardon my noise.
Re comment #35: not that the "Insert PRIMARY" keyboard shortcut is not configurable in Edit->Keyboard Shortcuts. Maybe it should...
vte itself doesn't have configurable keybindings, but higher levels (gnome-terminal) can override bindings. As Matthias said, gnome-terminal may add that option, but so far seems most people using shift+insert in the terminal is using it to paste PRIMARY. Probably because it has been like that though.
I dislike the reverting patch. It is very annoying for me, that gnome-terminal behaves others than the rest of the GNOME desktop. Shift+insert should be the default option at least for gnome-terminal.
I don't like it either. But I decided keeping the old behavior is a better strategy at this point...
At the moment it's unclear what you mean by "old behaviour", but at the moment (vte 0.20.5) Shft+Insert appears to paste PRIMARY. This has been brought up in roxterm's tracker too <https://sourceforge.net/tracker/?func=detail&atid=698428&aid=2780123&group_id=124080> and I too would suggest CLIPBOARD. The standard the keystroke comes from appears to be based on "modern" desktops, not traditional X. If there's a strong case for both sides, would you consider an option in VTE's API, something like vte_set_shift_insert_clipboard(...)? This would be tidier for applications (gnome-terminal, roxterm etc) than having to add a key event handler.
As the filer of the ROXterm ticket, I support Tony's suggestion. Undoubtedly you're dealing with competing interests and good arguments for correctness on both sides, and while the correct behavior may be more correct from a traditional X standpoint, it is experienced as incorrect for users coming from other platforms where the CUA standard Shift-insert key combination performs a paste and there s only one clipboard-like buffer.
Please don't add comments to closed bugs; they'll just get lost.
Should we open a new bug, or have the latest comments been noted by the appropriate developers?