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 571341 - emitting init string wipes out mouse buffer
emitting init string wipes out mouse buffer
Status: RESOLVED DUPLICATE of bug 789954
Product: vte
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on: 789954
Blocks:
 
 
Reported: 2009-02-11 19:47 UTC by Todd Lewis
Modified: 2018-03-05 20:33 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Todd Lewis 2009-02-11 19:47:39 UTC
Please describe the problem:
Emitting the xterm "init_2string", or more specifically, just the "Soft terminal reset (DECSTR)" portion of that string, causes vt/gnome-terminal to clear the mouse clip of previously selected text. Running a program which emits the terminal init string (which should include any program that uses the whole terminal display area) will cause text previously selected by the mouse to be forgotten.

Steps to reproduce:
1. Compile this program "vttest.c" as "vttest":

   #include <stdio.h>
   int main( int argc, char **argv ) {
     printf("%s","\33[!p" );
     return 0;
   }

Note: "\33[!p", or CSI ! p is part of xterms init_2string from terminfo. See "Xterm Control Sequences" (http://invisible-island.net/xterm/ctlseqs/ctlseqs.html).

2. Select some text in gnome-terminal.

3. Middle-click to verify that it pastes as expected.

4. Run vttest compiled above, 

5. Middle-click again. Text is lost.

Actual results:
Selected text is forgotten, not pastable via middle click.

Expected results:
Selected text would be pasted.

Does this happen every time?
Yes.

Other information:
This is different from what happens with xterm. In xterm (which uses the same terminfo strings), emitting init_2string or just the "\33[!p" portion of it does not affect the mouse clip at all.
Comment 1 Mariano Suárez-Alvarez 2009-02-11 20:02:46 UTC
Unless you do an explicit copy (with Control+Shift+C or a menu item) selecting text only sets the PRIMARY selection, not the CLIPBOARD. The current specs on clipboards say that PRIMARY is supposed to contain the currently selected text, and as soon as you clear the terminal screen, there is no text selected, so PRIMARY is cleared.

If you want a somewhat more persistent selection, you *have* to do an explicit copy into it. This is how things are supposed to work. 

Comment 2 Todd Lewis 2009-02-11 21:15:54 UTC
Fascinating. First of all, there's no "clearing the terminal screen" involved, although the procedure outlined above does (inappropriately I think) de-select the text in a gnome-terminal. Again, this behavior differs from xterm.

Second, I can open a gnome-terminal and an xterm side by side, and easily get into a situation where I can middle-click paste into the xterm but not the gnome-terminal. No sane user would expect this "feature".

I'm willing to accept that this behavior is documented as you describe, but that "this is how things are supposed to work" is a little harder to fathom. The user (certainly "this" user) expects text selected with the mouse to be available for middle-click insert into any location he's allowed to insert text until he selects additional text, even if the original window goes away or the original text disappears. If it's necessary to correct the documentation as well as the code, so be it.

I would appreciate it if you could direct me to the documentation concerning PRIMARY selections vs. CLIPBOARD. Thank you.
Comment 3 Mariano Suárez-Alvarez 2009-02-11 22:01:02 UTC
If I select some text in xterm and type any key, the selection is cleared. Right before pressing the key, middle-clicking elsewhere correctly pastes the selection; as soon as I press any key, and the selection is cleared, middle-clicking elsewhere does not paste anything (again correctly, because there is nothing currently selected) Therefore, I cannot do the following three steps of yours in xterm, for as soon as I try to type the command in step 4 the selection is cleared

  2. Select some text in gnome-terminal.
  3. Middle-click to verify that it pastes as expected.
  4. Run vttest compiled above (or simply run echo -e '\E[!p'...)

I can do the following, though:

   echo SELECT SOMETHING NOW; sleep 3; echo -e '\E[!p'; echo NOW; sleep 6;
  
both in xterm and in g-t. And then I can see a difference: gnome-terminal clears the selection when it gets '\E[!p' while xterm does not; this is done in vte.c:vte_terminal_reset, near the end, and should probably be done only if doing a full reset.



The reference for the accepted interpretation of how selections should work in X is <http://standards.freedesktop.org/clipboards-spec/clipboards-0.1.txt>.
Comment 4 Todd Lewis 2009-02-14 01:21:51 UTC
(In reply to comment #3)
> [...] And then I can see a difference: gnome-terminal
> clears the selection when it gets '\E[!p' while xterm does not; this is done in
> vte.c:vte_terminal_reset, near the end, and should probably be done only if
> doing a full reset.

Yes, I think that will address the issue I was running into sufficiently. Thank you.


> The reference for the accepted interpretation of how selections should work in
> X is <http://standards.freedesktop.org/clipboards-spec/clipboards-0.1.txt>.

Thanks for that, too. It's a good read, and clarifies at least some of the confusion people experience.

Comment 5 Egmont Koblinger 2018-03-05 20:33:02 UTC
I believe this has just been fixed for the forthcoming vte-0.52 release, in bug 789954. Marking as anachronistic dup.

*** This bug has been marked as a duplicate of bug 789954 ***