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 759404 - Keep selected text in each tab
Keep selected text in each tab
Status: RESOLVED OBSOLETE
Product: gnome-terminal
Classification: Core
Component: general
git master
Other Linux
: Normal enhancement
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-12-13 14:26 UTC by Egmont Koblinger
Modified: 2021-06-10 21:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Egmont Koblinger 2015-12-13 14:26:41 UTC
- Gnome-terminal:

1. Switch to tab1, highlight some text (let's say "text1"), Ctrl+Shift+C to copy to the clipboard, paste it somewhere else.

2. Switch to tab2, highlight some text (let's say "text2"), Ctrl+Shift+C, paste it somewhere.

3. Switch back to tab1, the selection is gone. You need to highlight "text1" again to be able to copy-paste it.

- Konsole, iTerm2, Mac's default terminal too if I recall correctly, Firefox, Chrome:

1., 2. as above.

3. Switch back to tab1. "text1" is still highlighted, pressing Ctrl+Shift+C copies to the clipboard without having to highlight it again.


I find this behavior really convenient and saves me a lot of time during my daily work on iterm.
Comment 1 Christian Persch 2015-12-13 14:56:46 UTC
This is done so that the selection corresponds to the X PRIMARY selection.

I'm ok with changing this.
Comment 2 Matthias Clasen 2015-12-13 21:42:32 UTC
I don't think you should break the PRIMARY <> selection correspondence. I would suggest to remember the selection for each tab and select it again on tab switch
Comment 3 Egmont Koblinger 2015-12-13 22:18:15 UTC
My proposed change would break the visual feedback (the expectation that the highlighted text is the same as PRIMARY would no longer hold) but would not break any workflow; whereas your proposed change would break the behavior (users might expect PRIMARY not to change on a tab change, and their workflow / muscle memory might no longer work). I find the latter more dangerous.

Konsole, FF & Chrome don't update PRIMARY on tab change. Having two kinds of copy-paste buffers sucks big time to begin with. Having two different behaviors in tabbed UIs is not nice either. Preferably I wouldn't introduce a third kind of behavior – I think that'd be more misleading than doing what firefox & chrome already do.

What I'm thinking about is using some dimmed color for selection if it no longer matches PRIMARY – would this sound good for you?
Comment 4 Egmont Koblinger 2015-12-13 22:24:02 UTC
Also note that this feature is not only useful when switching between g-t tabs; it's also useful when switching between g-t windows, or between other apps as well. So hooking up to a tab change wouldn't be enough, we should also hook up to focus change.

This probably wouldn't work reliably due to the infamous focus bug 677329. But even if that bug was fixed, I wouldn't think this is the right approach.
Comment 5 Matthias Clasen 2015-12-14 14:44:23 UTC
(In reply to Egmont Koblinger from comment #3)

> 
> What I'm thinking about is using some dimmed color for selection if it no
> longer matches PRIMARY – would this sound good for you?

No, thats the terrible firefox behavior. I absolutely hate that.
Comment 6 GNOME Infrastructure Team 2021-06-10 21:03:17 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7627.