Re: xterm bug
On Thu, Aug 18, 2011 at 10:17:31AM +0200, Mark Kettenis wrote: Makes no sense. The keepSelection check is already done in ScrnDisownSelection(). The only place where DisownSelection() is called directly is SelectSet(), and that should only happen if you explicitly shrink your selection to nothing. As far as I know, xterm keeps the selection just fine. If I select some text in one xterm, then click at some random place in that same xterm such that the text is no longer highlighted, I can paste it just fine into another xterm using the middle mouse button. Having done some simple tests, the situation seems to be like this: If you highlight some text in an xterm, it's copied to PRIMARY just fine and kept there if keepSelection is true. However, PRIMARY cannot be accessed by gtk apps, which use the CLIPBOARD. So most people do something like xterm*VT100.translations: #override Btn1Up: select-end(PRIMARY, CLIPBOARD, CUT _BUFFER0) in their .Xdefaults. And here's the problem: If you select text, it gets copied to both PRIMARY and CLIPBOARD. If you then click somewhere else in the same xterm, it is kept in PRIMARY, but *not* in CLIPBOARD (so it's lost for gtk apps). Hope this helps.
Re: xterm bug
On Thu, Aug 18, 2011 at 10:17:31AM +0200, Mark Kettenis wrote:
Date: Wed, 17 Aug 2011 16:11:55 -0500
From: Marco Peereboom ma...@peereboom.us
After the long debate yesterday about clipboards sucking major eggs and
stuff I started looking into the problem. One of the problems is that
xterm doesn't honor the Keep Selection flag. The code is a little
tangly but if I read it correctly it looks like a simple test was
missed. This brings xterm in line with all other applications
(including gtk ones) where, by default, if a selection is cleared on the
screen it ISN'T cleared from PRIMARY. People who desire the clearing of
PRIMARY should use the XTerm*keepSelection: false setting as described
in the manual.
This is just step one. The rest of the issues seem to be hidden in gtk.
Makes no sense. The keepSelection check is already done in
ScrnDisownSelection(). The only place where DisownSelection() is
called directly is SelectSet(), and that should only happen if you
explicitly shrink your selection to nothing.
It goes down another code path. This through me for a loop but the
trace shows this.
As far as I know, xterm keeps the selection just fine. If I select
some text in one xterm, then click at some random place in that same
xterm such that the text is no longer highlighted, I can paste it just
fine into another xterm using the middle mouse button.
But not in any application that doesn't use CUT_BUFFER0. Which these
days is about everything minus xterm. This diff brings xterm in line
with everything else and as far as I can see with the man page.
Index: button.c
===
RCS file: /cvs/xenocara/app/xterm/button.c,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 button.c
--- button.c7 Mar 2011 20:41:27 - 1.17
+++ button.c17 Aug 2011 21:01:24 -
@@ -3890,7 +3890,7 @@ DisownSelection(XtermWidget xw)
for (i = 0; i count; i++) {
int cutbuffer = CutBuffer(atoms[i]);
- if (cutbuffer 0) {
+ if (!screen-keepSelection cutbuffer 0) {
XtDisownSelection((Widget) xw, atoms[i],
screen-selection_time);
}
Re: xterm bug
Date: Thu, 18 Aug 2011 06:46:12 -0500 From: Marco Peereboom sl...@peereboom.us Hope this helps. It doesn't because this isn't what the man page states for keep selection. It only works with Scrn* functions and does not get tested when DisownSelection is called, which is called from some other spots directly as well instead of going through Scrn*. Only from buffer.c:SelectSet(), and there it makes sense to bypass ScrnDisownSelection() and the keepSelection check. You're barking up the wrong tree here Marco.
Re: xterm bug
On Thu, Aug 18, 2011 at 11:21:28AM +0200, Pascal Stumpf wrote: On Thu, Aug 18, 2011 at 10:17:31AM +0200, Mark Kettenis wrote: Makes no sense. The keepSelection check is already done in ScrnDisownSelection(). The only place where DisownSelection() is called directly is SelectSet(), and that should only happen if you explicitly shrink your selection to nothing. As far as I know, xterm keeps the selection just fine. If I select some text in one xterm, then click at some random place in that same xterm such that the text is no longer highlighted, I can paste it just fine into another xterm using the middle mouse button. Having done some simple tests, the situation seems to be like this: If you highlight some text in an xterm, it's copied to PRIMARY just fine and kept there if keepSelection is true. However, PRIMARY cannot be accessed by gtk apps, which use the CLIPBOARD. So most people do something like xterm*VT100.translations: #override Btn1Up: select-end(PRIMARY, CLIPBOARD, CUT _BUFFER0) in their .Xdefaults. And here's the problem: If you select text, it gets copied to both PRIMARY and CLIPBOARD. If you then click somewhere else in the same xterm, it is kept in PRIMARY, but *not* in CLIPBOARD (so it's lost for gtk apps). This is the behavior that should happen with xterm*keepSelection: false Hope this helps. It doesn't because this isn't what the man page states for keep selection. It only works with Scrn* functions and does not get tested when DisownSelection is called, which is called from some other spots directly as well instead of going through Scrn*.
Re: xterm bug
On Thu, Aug 18, 2011 at 02:45:37PM +0200, Pascal Stumpf wrote: On Thu, Aug 18, 2011 at 06:46:12AM -0500, Marco Peereboom wrote: It doesn't because this isn't what the man page states for keep selection. It only works with Scrn* functions and does not get tested when DisownSelection is called, which is called from some other spots directly as well instead of going through Scrn*. No. It does what the manpage says: Keep the selection (= PRIMARY). Copying that to CLIPBOARD is a customisation that has nothing to do with keepSelection. That isn't what the diff does. Anyway, more on the PRIMARY vs. CLIPBOARD problem: http://www.freedesktop.org/wiki/Specifications/ClipboardsWiki?action=showredirect=Standards%2FClipboardsWiki I am well aware of this document and the spec. So xterm cannot (by default) even copy stuff into CLIPBOARD by mere selection without violating the ICCCM. Imho, the correct way to solve this would be to implement explicit cut/copy/paste commands; and that way, it would truly handle both buffers like all other applications. In any case, something like this should probably go upstream. Here is my script to test: $ cat /home/marco/bin/showclip.sh #!/bin/sh for c in clipboard primary secondary do echo == $c xclip -o -selection $c echo done echo == cut_buffer0 xprop -root -len 1024 CUT_BUFFER0 The Keep Selection option _doesn't_ do anything at all. Go through this use case to see it in action: 1 select something in xterm 2 run showclip.sh note how primary and cut_buffer0 have the same content 3 click on the same xterm ans watch the highlighting dissapear 4 run showclip.sh note how primary is cleared and cut_buffer0 still has the previous content Now we can argue if that is intended or not but what I read in the man page and ctlseqs.txt is that this option is a toggle for that. Let me quote ctlseqs.txt Ps = 1 0 4 0 - Keep selection even if not highlighted. (This enables the keepSelection resource).. Additionally, cut buffers have been deprecated. This means that all modern applications that no longer look at them can no longer effectively copy between xterm and said modern application (like gtk apps). Now lets go one further, if you set the selectToClipboard resource to true, the same behavior occurs. This violates clipboard behavior and the principle of least astonishment. Lastly, and this a slightly weaker argument however, here goes. All the other applications do NOT clear primary when text is unhighlighted. xterm is the odd one out doing it's own thing. I have not run across any other app that exhibits this behavior. The diff makes keepSelection work the way the man page and the ctlseqs.txt document (at least the way I read it) AND the user gets to pick which behavior he/she prefers.
Re: xterm bug
On Thu, Aug 18, 2011 at 09:37:33AM -0500, Marco Peereboom wrote:
On Wed, Aug 17, 2011 at 04:11:55PM -0500, Marco Peereboom wrote:
After the long debate yesterday about clipboards sucking major eggs and
stuff I started looking into the problem.
Where was that discussion? I seem to have missed it.
; One of the problems is that
xterm doesn't honor the Keep Selection flag. The code is a little
tangly but if I read it correctly it looks like a simple test was
missed. This brings xterm in line with all other applications
(including gtk ones) where, by default, if a selection is cleared on the
screen it ISN'T cleared from PRIMARY. People who desire the clearing of
PRIMARY should use the XTerm*keepSelection: false setting as described
in the manual.
I've seen cases where the xterm selection seems to stick too much
too. I haven't had time to track the issue so I don't have further
opinions on this for now.
May I suggest that you include XTerm's developper Thomas Dickey
(dic...@invisible-island.net) in the discussion about this issue?
In the mean time I'll commit the update to version 271 that people
tested before tree lock. It doesn't change this behaviour.
This is just step one. The rest of the issues seem to be hidden in gtk.
Index: button.c
===
RCS file: /cvs/xenocara/app/xterm/button.c,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 button.c
--- button.c7 Mar 2011 20:41:27 - 1.17
+++ button.c17 Aug 2011 21:01:24 -
@@ -3890,7 +3890,7 @@ DisownSelection(XtermWidget xw)
for (i = 0; i count; i++) {
int cutbuffer = CutBuffer(atoms[i]);
- if (cutbuffer 0) {
+ if (!screen-keepSelection cutbuffer 0) {
XtDisownSelection((Widget) xw, atoms[i],
screen-selection_time);
}
Actually this seems to be a much better patch.
Index: button.c
===
RCS file: /cvs/xenocara/app/xterm/button.c,v
retrieving revision 1.17
diff -u -p -r1.17 button.c
--- button.c 7 Mar 2011 20:41:27 - 1.17
+++ button.c 18 Aug 2011 14:12:19 -
@@ -2308,7 +2308,7 @@ SelectSet(XtermWidget xw,
if (!isSameCELL((screen-startSel), (screen-endSel))) {
SaltTextAway(xw, (screen-startSel), (screen-endSel), params,
num_params);
} else {
- DisownSelection(xw);
+ ScrnDisownSelection(xw);
}
}
--
Matthieu Herrb
