GNU bug report logs - #29150
26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: olaf.rogalsky <at> t-online.de, 29150 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Thu, 09 Nov 2017 17:47:15 +0200

> From: Alex <agrambot <at> gmail.com>
> Cc: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>,  Eli Zaretskii <eliz <at> gnu.org>,  29150 <at> debbugs.gnu.org
> Date: Thu, 09 Nov 2017 00:26:44 -0600
> 
> Assuming that no one ports evil-mode's code or updates the code in
> `mouse-drag-secondary' (there's already a FIXME for this there), is
> using `read-key' inside of `track-mouse' an acceptable stopgap solution?

It could be, but I don't think we understand all the consequences of
this to be sure.

> Is it brittle enough to not apply the change to emacs-26?

Yes, it's too risky for the release branch.  With all due respect to
xterm-mouse, it's a niche feature, so putting the vast majority of
mouse users at risk on its behalf doesn't sound justified.

So I think we should put that on master and see what happens.

> > In my experience, most uses of `read-event` are (latent) bugs, so maybe
> > it's in read-event's docstring that we should say something.
> 
> That sounds like a good idea.

Patches to this latter effect are welcome on emacs-26.

Thanks.

Previous Next

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