GNU bug report logs - #24420
25.1.50; Work around terminal differences for bracketed-paste/mouse-2

Previous Next

To reply to this bug, email your comments to 24420 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1.50; Work around terminal differences for bracketed-paste/mouse-2
Date: Mon, 12 Sep 2016 15:39:25 +0200

There are several terminals that announce themselves as XTerm and
partially implement the XTerm control sequences
(http://invisible-island.net/xterm/ctlseqs/ctlseqs.html), but have some
slightly different behavior.  I've tried out XTerm, HTerm, and
gnome-terminal, and found the following behavior differences:

- XTerm sends xterm-paste (ESC [ 200~ ... ESC [ 201~) if
  xterm-mouse-mode is disabled.  If xterm-mouse-mode is enabled, it
  sends down-mouse-2 + up-mouse-2 using SGR coordinates (ESC [<1;x;yM
  ESC [<1;x;ym), which gets translated to mouse-yank-primary.

- Gnome Terminal sends xterm-paste if xterm-mouse-mode is disabled.  If
  xterm-mouse-mode is enabled, it only sends down-mouse-2 using SGR
  coordinates, which is ignored by Emacs.

- HTerm doesn't use bracketed paste mode if xterm-mouse-mode is disabled
  (i.e. pasted text gets inserted using individual
  self-insert-commands).  If xterm-mouse-mode is enabled, it uses both
  (!) down-mouse-2 + down-mouse-up (using basic coordinates) and then a
  bracketed paste.

The HTerm and Gnome-Terminal behaviors are probably bugs, and I'll try
to get them fixed.  However, maybe we want to work around these issues
on the Emacs side, e.g. by not requiring an up-mouse-2 if
xterm-mouse-mode is enabled.


In GNU Emacs 25.1.50.4 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2016-09-05 built on unknown
Repository revision: 6acff25280dbb97b5e9ddfd872b33ceb36b0470a
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04 LTS

Configured using:
 'configure --with-modules'

Configured features:
XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 97721 6855)
 (symbols 48 20654 0)
 (miscs 40 325 144)
 (strings 32 17939 4381)
 (string-bytes 1 588434)
 (vectors 16 13774)
 (vector-slots 8 451984 3705)
 (floats 8 183 31)
 (intervals 56 199 0)
 (buffers 976 12)
 (heap 1024 32176 1173))

-- 
Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Diese E-Mail ist vertraulich.  Wenn Sie nicht der richtige Adressat sind,
leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen
Sie die E-Mail und alle Anhänge.  Vielen Dank.

This e-mail is confidential.  If you are not the right addressee please do not
forward it, please inform the sender, and please erase this e-mail including
any attachments.  Thanks.

Message #8 received at 24420 <at> debbugs.gnu.org (full text, mbox):

From: Robert Cochran <robert-emacs <at> cochranmail.com>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24420 <at> debbugs.gnu.org
Subject: Re: bug#24420: 25.1.50;
 Work around terminal differences for bracketed-paste/mouse-2
Date: Wed, 14 Sep 2016 11:36:57 -0700

Philipp Stephani <p.stephani2 <at> gmail.com> writes:

> There are several terminals that announce themselves as XTerm and
> partially implement the XTerm control sequences
> (http://invisible-island.net/xterm/ctlseqs/ctlseqs.html), but have some
> slightly different behavior.

That sounds like breakage waiting to happen. Maybe I'm not entirely
familiar with how things are done in terminal-emulator-land, but why
would you declare yourself as an XTerm if you only partially implement
or differ from the real thing? _That_ sounds like the bug to me. Don't
claim to be something you're not. When a program *still* has to account
for differences in terminals after getting a terminal descriptor, then
IMO you've lost the whole point of term{cap,info}.

How does one get new entries into the database (and curses) nowadays
anyhow? Maybe part of the problem here is that people piggy-back off of
xterm's descriptor because they don't have their own entry... Also, how
do you communicate the advanced features (like mouse support)? Is it
simply that it's there if a terminal claims to be an xterm? Or is there
a real query method for those things?

> I've tried out XTerm, HTerm, and gnome-terminal, and found the
> following behavior differences:
>
> - XTerm sends xterm-paste (ESC [ 200~ ... ESC [ 201~) if
>   xterm-mouse-mode is disabled.  If xterm-mouse-mode is enabled, it
>   sends down-mouse-2 + up-mouse-2 using SGR coordinates (ESC [<1;x;yM
>   ESC [<1;x;ym), which gets translated to mouse-yank-primary.
>
> - Gnome Terminal sends xterm-paste if xterm-mouse-mode is disabled.  If
>   xterm-mouse-mode is enabled, it only sends down-mouse-2 using SGR
>   coordinates, which is ignored by Emacs.
>
> - HTerm doesn't use bracketed paste mode if xterm-mouse-mode is disabled
>   (i.e. pasted text gets inserted using individual
>   self-insert-commands).  If xterm-mouse-mode is enabled, it uses both
>   (!) down-mouse-2 + down-mouse-up (using basic coordinates) and then a
>   bracketed paste.
>
> The HTerm and Gnome-Terminal behaviors are probably bugs, and I'll try
> to get them fixed.  However, maybe we want to work around these issues
> on the Emacs side, e.g. by not requiring an up-mouse-2 if
> xterm-mouse-mode is enabled.

I could go either way on this one... Emacs maybe ought not to be so
choosy about what it gets from a control character standpoint, but how
relatively difficuly would it be to fix the emulators to do both up and
down? That way both flavors of program are satisfied: the ones looking
for down-only get their event, and those looking for both get both.

-- 
~Robert Cochran

GPG Fingerprint - E778 2DD4 FEA6 6A68 6F26  AD2D E5C3 EB36 4886 8871

Message #11 received at 24420 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Robert Cochran <robert-emacs <at> cochranmail.com>
Cc: 24420 <at> debbugs.gnu.org
Subject: Re: bug#24420: 25.1.50;
 Work around terminal differences for bracketed-paste/mouse-2
Date: Wed, 14 Sep 2016 20:05:21 +0000

[Message part 1 (text/plain, inline)]

Robert Cochran <robert-emacs <at> cochranmail.com> schrieb am Mi., 14. Sep. 2016
um 20:37 Uhr:

> Philipp Stephani <p.stephani2 <at> gmail.com> writes:
>
> > There are several terminals that announce themselves as XTerm and
> > partially implement the XTerm control sequences
> > (http://invisible-island.net/xterm/ctlseqs/ctlseqs.html), but have some
> > slightly different behavior.
>
> That sounds like breakage waiting to happen. Maybe I'm not entirely
> familiar with how things are done in terminal-emulator-land, but why
> would you declare yourself as an XTerm if you only partially implement
> or differ from the real thing?


For the same reason that every web browser on the planet declares itself as
"Mozilla". Identification strings simply don't work.


how do you communicate the advanced features (like mouse support)? Is it
> simply that it's there if a terminal claims to be an xterm? Or is there
> a real query method for those things?
>

That's not really possible. Basically Emacs tries to enable all features
and assumes the terminal emulator simply ignores escape sequences it
doesn't understand.


>
> > I've tried out XTerm, HTerm, and gnome-terminal, and found the
> > following behavior differences:
> >
> > - XTerm sends xterm-paste (ESC [ 200~ ... ESC [ 201~) if
> >   xterm-mouse-mode is disabled.  If xterm-mouse-mode is enabled, it
> >   sends down-mouse-2 + up-mouse-2 using SGR coordinates (ESC [<1;x;yM
> >   ESC [<1;x;ym), which gets translated to mouse-yank-primary.
> >
> > - Gnome Terminal sends xterm-paste if xterm-mouse-mode is disabled.  If
> >   xterm-mouse-mode is enabled, it only sends down-mouse-2 using SGR
> >   coordinates, which is ignored by Emacs.
> >
> > - HTerm doesn't use bracketed paste mode if xterm-mouse-mode is disabled
> >   (i.e. pasted text gets inserted using individual
> >   self-insert-commands).  If xterm-mouse-mode is enabled, it uses both
> >   (!) down-mouse-2 + down-mouse-up (using basic coordinates) and then a
> >   bracketed paste.
> >
> > The HTerm and Gnome-Terminal behaviors are probably bugs, and I'll try
> > to get them fixed.  However, maybe we want to work around these issues
> > on the Emacs side, e.g. by not requiring an up-mouse-2 if
> > xterm-mouse-mode is enabled.
>
> I could go either way on this one... Emacs maybe ought not to be so
> choosy about what it gets from a control character standpoint, but how
> relatively difficuly would it be to fix the emulators to do both up and
> down? That way both flavors of program are satisfied: the ones looking
> for down-only get their event, and those looking for both get both.
>
>
Fixing gnome-terminal would be preferred, yes, but old (unfixed) versions
tend to stick around for years.
With HTerm it's a bit different: arguably HTerm's behavior is better than
XTerm's, because with XTerm you can't paste any more once you enable
extended mouse mode.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.