GNU logs - #24420, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#24420: 25.1.50; Work around terminal differences for bracketed-paste/mouse-2
Resent-From: Philipp Stephani <p.stephani2@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 12 Sep 2016 13:41:02 +0000
Resent-Message-ID: <handler.24420.B.14736876537889 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 24420 <at> debbugs.gnu.org
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Mon, 12 Sep 2016 15:39:25 +0200
Message-ID: <wvr4lgyxxmnm.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>


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))

--=20
Google Germany GmbH
Erika-Mann-Stra=C3=9Fe 33
80636 M=C3=BCnchen

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Gesch=C3=A4ftsf=C3=BChrer: 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=C3=
=B6schen
Sie die E-Mail und alle Anh=C3=A4nge.  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 sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Philipp Stephani <p.stephani2@HIDDEN>
Subject: bug#24420: Acknowledgement (25.1.50; Work around terminal
 differences for bracketed-paste/mouse-2)
Message-ID: <handler.24420.B.14736876537889.ack <at> debbugs.gnu.org>
References: <wvr4lgyxxmnm.fsf@HIDDEN>
X-Gnu-PR-Message: ack 24420
X-Gnu-PR-Package: emacs
Reply-To: 24420 <at> debbugs.gnu.org
Date: Mon, 12 Sep 2016 13:41:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 24420 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
24420: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D24420
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#24420: 25.1.50; Work around terminal differences for bracketed-paste/mouse-2
Resent-From: Robert Cochran <robert-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 14 Sep 2016 18:38:01 +0000
Resent-Message-ID: <handler.24420.B24420.147387822520858 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Philipp Stephani <p.stephani2@HIDDEN>
Cc: 24420 <at> debbugs.gnu.org
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=private; d=cochranmail.com;
 b=MDJC6o9VhHU7yrQiJochHEtJI+HORFHcclECtvtqPW+iWFx0CHY0gbPsdkH+kNGOE2//SJSrIFEhuDsQUSjKAw==;
From: Robert Cochran <robert-emacs@HIDDEN>
References: <wvr4lgyxxmnm.fsf@HIDDEN>
Date: Wed, 14 Sep 2016 11:36:57 -0700
In-Reply-To: <wvr4lgyxxmnm.fsf@HIDDEN> (Philipp Stephani's
 message of "Mon, 12 Sep 2016 15:39:25 +0200")
Message-ID: <8737l2pbue.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Philipp Stephani <p.stephani2@HIDDEN> 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 sent to bug-gnu-emacs@HIDDEN:

Subject: bug#24420: 25.1.50; Work around terminal differences for bracketed-paste/mouse-2
Resent-From: Philipp Stephani <p.stephani2@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 14 Sep 2016 20:06:02 +0000
Resent-Message-ID: <handler.24420.B24420.147388354129084 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Robert Cochran <robert-emacs@HIDDEN>
Cc: 24420 <at> debbugs.gnu.org
MIME-Version: 1.0
References: <wvr4lgyxxmnm.fsf@HIDDEN>
 <8737l2pbue.fsf@HIDDEN>
In-Reply-To: <8737l2pbue.fsf@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Wed, 14 Sep 2016 20:05:21 +0000
Message-ID: <CAArVCkTbTheXE5bD9RBRXb_ECcpXSwd87bqLtq7wc-cjj2x4aQ@HIDDEN>
Content-Type: multipart/alternative; boundary=047d7ba97a1063bfeb053c7d40b2
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--047d7ba97a1063bfeb053c7d40b2
Content-Type: text/plain; charset=UTF-8

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

> Philipp Stephani <p.stephani2@HIDDEN> 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.

--047d7ba97a1063bfeb053c7d40b2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">Robert=
 Cochran &lt;<a href=3D"mailto:robert-emacs@HIDDEN">robert-emacs@c=
ochranmail.com</a>&gt; schrieb am Mi., 14. Sep. 2016 um 20:37=C2=A0Uhr:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">Philipp Stephani &lt;<a href=3D"mailto=
:p.stephani2@HIDDEN" class=3D"gmail_msg" target=3D"_blank">p.stephani2@g=
mail.com</a>&gt; writes:<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; There are several terminals that announce themselves as XTerm and<br c=
lass=3D"gmail_msg">
&gt; partially implement the XTerm control sequences<br class=3D"gmail_msg"=
>
&gt; (<a href=3D"http://invisible-island.net/xterm/ctlseqs/ctlseqs.html" re=
l=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">http://invisible-isl=
and.net/xterm/ctlseqs/ctlseqs.html</a>), but have some<br class=3D"gmail_ms=
g">
&gt; slightly different behavior.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
That sounds like breakage waiting to happen. Maybe I&#39;m not entirely<br =
class=3D"gmail_msg">
familiar with how things are done in terminal-emulator-land, but why<br cla=
ss=3D"gmail_msg">
would you declare yourself as an XTerm if you only partially implement<br c=
lass=3D"gmail_msg">
or differ from the real thing?</blockquote><div><br></div><div>For the same=
 reason that every web browser on the planet declares itself as &quot;Mozil=
la&quot;. Identification strings simply don&#39;t work.</div><div>=C2=A0</d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">how do you communicate the=
 advanced features (like mouse support)? Is it<br class=3D"gmail_msg">
simply that it&#39;s there if a terminal claims to be an xterm? Or is there=
<br class=3D"gmail_msg">
a real query method for those things?<br class=3D"gmail_msg"></blockquote><=
div><br></div><div>That&#39;s not really possible. Basically Emacs tries to=
 enable all features and assumes the terminal emulator simply ignores escap=
e sequences it doesn&#39;t understand.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<br class=3D"gmail_msg">
&gt; I&#39;ve tried out XTerm, HTerm, and gnome-terminal, and found the<br =
class=3D"gmail_msg">
&gt; following behavior differences:<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; - XTerm sends xterm-paste (ESC [ 200~ ... ESC [ 201~) if<br class=3D"g=
mail_msg">
&gt;=C2=A0 =C2=A0xterm-mouse-mode is disabled.=C2=A0 If xterm-mouse-mode is=
 enabled, it<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0sends down-mouse-2 + up-mouse-2 using SGR coordinates (ESC=
 [&lt;1;x;yM<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0ESC [&lt;1;x;ym), which gets translated to mouse-yank-prim=
ary.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; - Gnome Terminal sends xterm-paste if xterm-mouse-mode is disabled.=C2=
=A0 If<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0xterm-mouse-mode is enabled, it only sends down-mouse-2 us=
ing SGR<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0coordinates, which is ignored by Emacs.<br class=3D"gmail_=
msg">
&gt;<br class=3D"gmail_msg">
&gt; - HTerm doesn&#39;t use bracketed paste mode if xterm-mouse-mode is di=
sabled<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0(i.e. pasted text gets inserted using individual<br class=
=3D"gmail_msg">
&gt;=C2=A0 =C2=A0self-insert-commands).=C2=A0 If xterm-mouse-mode is enable=
d, it uses both<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0(!) down-mouse-2 + down-mouse-up (using basic coordinates)=
 and then a<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0bracketed paste.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; The HTerm and Gnome-Terminal behaviors are probably bugs, and I&#39;ll=
 try<br class=3D"gmail_msg">
&gt; to get them fixed.=C2=A0 However, maybe we want to work around these i=
ssues<br class=3D"gmail_msg">
&gt; on the Emacs side, e.g. by not requiring an up-mouse-2 if<br class=3D"=
gmail_msg">
&gt; xterm-mouse-mode is enabled.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
I could go either way on this one... Emacs maybe ought not to be so<br clas=
s=3D"gmail_msg">
choosy about what it gets from a control character standpoint, but how<br c=
lass=3D"gmail_msg">
relatively difficuly would it be to fix the emulators to do both up and<br =
class=3D"gmail_msg">
down? That way both flavors of program are satisfied: the ones looking<br c=
lass=3D"gmail_msg">
for down-only get their event, and those looking for both get both.<br clas=
s=3D"gmail_msg">
<br class=3D"gmail_msg"></blockquote><div><br></div><div>Fixing gnome-termi=
nal would be preferred, yes, but old (unfixed) versions tend to stick aroun=
d for years.</div><div>With HTerm it&#39;s a bit different: arguably HTerm&=
#39;s behavior is better than XTerm&#39;s, because with XTerm you can&#39;t=
 paste any more once you enable extended mouse mode.=C2=A0</div></div></div=
>

--047d7ba97a1063bfeb053c7d40b2--

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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