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
Subject: bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Mon, 13 Nov 2017 17:51:23 +0200

> From: Alex <agrambot <at> gmail.com>
> Cc: olaf.rogalsky <at> t-online.de,  29150 <at> debbugs.gnu.org
> Date: Sun, 12 Nov 2017 18:00:57 -0600
> 
> >> Perhaps the patch should be replaced on the master branch with one that
> >> uses `read-key' in all cases?
> >
> > Why the rush?
> 
> I don't mean to rush anything, but I figured that I should mention it
> before I forget about it.

The thing is, I'm not yet sure read-key is TRT in this case.  We have
a lousy record in our changes of input processing code: almost every
change caused subtle bugs that took many moons to find and fix.  I
think we should recognize this vulnerability and behave more
cautiously.

> > If you want this on the release branch, it should be affect only
> > xt-mouse.  If you propose this for master, see above.
> 
> Do you mean that I shouldn't rush the `read-key' change for
> `mouse-drag-secondary' in master, either?

I'd like first to see how it fares on the release branch (and on
master), when it is limited to xt-mouse.

> Would applying the previous diff for master and the following for
> emacs-26 be acceptable?

Looks OK for the release branch (from which it will be merged to
master).  I'd prefer to wait with a more radical change even on
master.  Maybe put a FIXME comment there, to the effect that we should
try removing the condition at some point.

Thanks.

Previous Next

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