After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 123844 - Select after copy overwrites clipboard contents
Select after copy overwrites clipboard contents
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.11.x
Other All
: Normal enhancement
: ---
Assigned To: VTE Maintainers
VTE Maintainers
: 121758 143544 162962 331152 (view as bug list)
Depends on: 603169
Blocks:
 
 
Reported: 2003-10-04 19:33 UTC by Behdad Esfahbod
Modified: 2009-11-27 18:40 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
My proposed solution - don't use callbacks for clipboard selection (686 bytes, patch)
2005-08-21 16:58 UTC, Chris Heath
none Details | Review
committed patch. (3.94 KB, patch)
2006-02-02 03:44 UTC, Behdad Esfahbod
committed Details | Review

Description Behdad Esfahbod 2003-10-04 19:33:29 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.
Comment 1 Havoc Pennington 2003-10-04 22:50:04 UTC
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.
Comment 2 Behdad Esfahbod 2003-10-04 22:55:10 UTC
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.
Comment 3 Behdad Esfahbod 2003-10-04 22:56:22 UTC
Oops, I shouldn't have changed the bug status.  Sorry.
Comment 4 Adam Hooper 2003-10-04 23:51:10 UTC
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.
Comment 5 Behdad Esfahbod 2003-10-04 23:56:23 UTC
So the bug is there.  NO??
Comment 6 Behdad Esfahbod 2003-10-04 23:59:29 UTC
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.
Comment 7 Havoc Pennington 2003-10-05 01:08:33 UTC
I see, thanks. Sounds broken.
Comment 8 Kjartan Maraas 2005-02-14 23:58:09 UTC
Retitling.
Comment 9 Michele Baldessari 2005-06-26 19:32:20 UTC
*** Bug 162962 has been marked as a duplicate of this bug. ***
Comment 10 Michele Baldessari 2005-06-26 21:00:50 UTC
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>
Comment 11 Michele Baldessari 2005-07-26 18:46:23 UTC
*** Bug 121758 has been marked as a duplicate of this bug. ***
Comment 12 Michele Baldessari 2005-07-26 19:08:54 UTC
*** Bug 143544 has been marked as a duplicate of this bug. ***
Comment 13 Michele Baldessari 2005-07-26 19:09:47 UTC
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...
"""
Comment 14 Chris Heath 2005-08-21 16:58:45 UTC
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.
Comment 15 Behdad Esfahbod 2006-02-02 03:44:17 UTC
Created attachment 58560 [details] [review]
committed patch.

I believe I fixed this.
Comment 16 Mateus César Gröess 2006-02-13 16:08:51 UTC
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.
Comment 17 Behdad Esfahbod 2006-02-13 18:39:01 UTC
The Shift+Insert behavior is consistent with all other GNOME apps.
I'm going to make Ctrl+Shift+Insert paste PRIMARY.  How's that?
Comment 18 Behdad Esfahbod 2006-02-13 20:50:35 UTC
2006-02-13  Behdad Esfahbod  <behdad@gnome.org>

        * src/vte.c (vte_terminal_key_press): Handle Ctrl+Shift+Insert to
        paste PRIMARY.

Comment 19 Matthias Clasen 2006-02-14 06:14:22 UTC
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.
Comment 20 Behdad Esfahbod 2006-02-14 07:37:54 UTC
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.
Comment 21 Mart Raudsepp 2006-02-14 07:57:40 UTC
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.
Comment 22 Nalin Dahyabhai 2006-02-14 15:11:41 UTC
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).
Comment 23 Behdad Esfahbod 2006-02-14 16:34:03 UTC
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.
Comment 24 Behdad Esfahbod 2006-02-14 16:34:24 UTC
*** Bug 331152 has been marked as a duplicate of this bug. ***
Comment 25 Carl Worth 2006-02-14 16:41:42 UTC
(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?
Comment 26 Behdad Esfahbod 2006-02-14 16:56:47 UTC
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.
Comment 27 Carl Worth 2006-02-14 17:12:34 UTC
(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".
Comment 28 James Cloos 2006-02-14 19:00:52 UTC
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.
Comment 29 Behdad Esfahbod 2006-02-14 19:10:56 UTC
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.
Comment 30 Martijn van de Streek 2006-02-14 20:01:23 UTC
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!')
Comment 31 Frank Hart 2006-02-15 17:53:52 UTC
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! :-)
Comment 32 Behdad Esfahbod 2006-02-17 06:10:55 UTC
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?
Comment 33 Mart Raudsepp 2006-02-17 07:45:45 UTC
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.
Comment 34 Behdad Esfahbod 2006-02-17 12:37:15 UTC
Ok, I made shift+insert paste PRIMARY and ctrl+shift+insert paste CLIPBOARD.
Comment 35 Carl Worth 2006-02-17 18:15:02 UTC
(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


Comment 36 Carl Worth 2006-02-17 18:29:11 UTC
(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.
Comment 37 Matthias Clasen 2006-02-17 19:48:49 UTC
Re comment #35: not that the "Insert PRIMARY" keyboard shortcut is not
configurable in Edit->Keyboard Shortcuts. Maybe it should...
Comment 38 Behdad Esfahbod 2006-02-17 20:01:58 UTC
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.
Comment 39 Petr Tomasek 2006-02-27 20:18:21 UTC
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.
Comment 40 Behdad Esfahbod 2006-02-28 01:07:48 UTC
I don't like it either.  But I decided keeping the old behavior is a better strategy at this point...
Comment 41 Tony Houghton 2009-06-25 11:14:35 UTC
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.
Comment 42 Tom Metro 2009-06-25 21:04:17 UTC
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.
Comment 43 Christian Persch 2009-06-25 22:11:28 UTC
Please don't add comments to closed bugs; they'll just get lost.
Comment 44 Tony Houghton 2009-06-25 23:14:56 UTC
Should we open a new bug, or have the latest comments been noted by the appropriate developers?