[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#901249: xterm: translation overrides for copy/paste do not work as documented



Package: xterm
Version: 333-1
Severity: normal

I was working on my .Xresources and found this quite crazy.
I could not select PRIMARY and CLIPBOARD independent of each
other. To reproduce, I chose to have *only* the lines from
the manual page…

           *VT100*translations:    #override \n\
              ~Shift~Ctrl<Btn2Up>: insert-selection(PRIMARY, CUT_BUFFER0) \n\
               Shift~Ctrl<Btn2Up>: insert-selection(CLIPBOARD, CUT_BUFFER1) \n\
              ~Shift     <BtnUp> : select-end(PRIMARY, CUT_BUFFER0) \n\
               Shift     <BtnUp> : select-end(CLIPBOARD, CUT_BUFFER1)

… loaded with “xrdb -merge filename”, with no .Xresources
at all, then I started two xterms, in one I selected, in
another, I ran xsel commands to discern what is the content
of PRIMARY and CLIPBOARD, respectively.

tglase@tglase-nb:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<> C<>
tglase@tglase-nb:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<foo> C<>
tglase@tglase-nb:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<bar> C<bar>
tglase@tglase-nb:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<foo> C<foo>

After the first command I selected “foo” without Shift.
⇒ as expected, PRIMARY gets assigned “foo”, CLIPBOARD is left alone
After the second command I selected “bar” with Shift.
⇒ unexpectedly, PRIMARY *also* gets “bar” in addition to CLIPBOARD
After the third line, I selected “foo” without Shift again.
⇒ unexpectedly, CLIPBOARD *also* gets “foo” in addition to PRIMARY


For comparison, here’s the same sequence of things on MirBSD,
with xterm 200 on XFree86:

tg@blau:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<> C<>
tg@blau:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<foo> C<>
tg@blau:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<bar> C<bar>
tg@blau:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<foo> C<>

For that, I used this in .Xresources though:

*VT100*translations: #override \n\
	 Shift~Ctrl<KeyPress>Insert:insert-selection(PRIMARY, CUT_BUFFER0) \n\
	 Shift Ctrl<KeyPress>Insert:insert-selection(CLIPBOARD, CUT_BUFFER1) \n\
	~Shift~Ctrl<Btn2Up>:insert-selection(PRIMARY, CUT_BUFFER0) \n\
	 Shift~Ctrl<Btn2Up>:insert-selection(CLIPBOARD, CUT_BUFFER1) \n\
	~Shift<BtnUp>:select-end(PRIMARY, CUT_BUFFER0) \n\
	 Shift<BtnUp>:select-end(CLIPBOARD, CUT_BUFFER1)

(Actually, do I need a trailing \n or \n\ after the last line?)

Here, selecting “foo” without Shift again *clears* CLIPBOARD
instead of assigning to it. Still buggy.


I was considering not using cut buffers in xterm 333 on X.org:

*VT100*translations: #override \n\
	 Shift~Ctrl<KeyPress>Insert:insert-selection(PRIMARY) \n\
	 Shift Ctrl<KeyPress>Insert:insert-selection(CLIPBOARD) \n\
	~Shift~Ctrl<Btn2Up>:insert-selection(PRIMARY) \n\
	 Shift~Ctrl<Btn2Up>:insert-selection(CLIPBOARD) \n\
	~Shift<BtnUp>:select-end(PRIMARY) \n\
	 Shift<BtnUp>:select-end(CLIPBOARD) \n\

Anyway, from the above tests I concur that this never worked
as documented and still does not work as documented.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages xterm depends on:
ii  libc6           2.27-3
ii  libfontconfig1  2.13.0-5
ii  libfreetype6    2.8.1-2
ii  libice6         2:1.0.9-2
ii  libtinfo6       6.1+20180210-3
ii  libutempter0    1.1.6-3
ii  libx11-6        2:1.6.5-1
ii  libxaw7         2:1.0.13-1+b2
ii  libxft2         2.3.2-2
ii  libxinerama1    2:1.1.3-1+b3
ii  libxmu6         2:1.1.2-2
ii  libxpm4         1:3.5.12-1
ii  libxt6          1:1.1.5-1
ii  xbitmaps        1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+4

Versions of packages xterm suggests:
pn  xfonts-cyrillic  <none>

-- no debconf information

Reply to: