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

Previous Next

Full log

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

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

> From: Alex <agrambot <at> gmail.com>
> Cc: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>,  29150 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Date: Sun, 12 Nov 2017 02:25:22 -0600
> 
> > Thanks, I installed that patch on the release branch.
> 
> Should it use `read-key' instead?

If that does TRT for xt-mouse, I'm okay with doing that.  But please
wait for Olaf to respond, it's his code after all.

> Perhaps the patch should be replaced on the master branch with one that
> uses `read-key' in all cases?

Why the rush?

> > Should we close this bug now, or is there anything else to do with it?
> 
> The first issue is fixed, but not the second (`mouse-drag-secondary'
> uses `read-event'). Here's a diff for the second:

If you want this on the release branch, it should be affect only
xt-mouse.  If you propose this for master, see above.

> > Btw, it seems like "C-h k" is not really working for complex mouse
> > clicks even without xterm-mouse-mode.  For example, try this:
> >
> >   C-h k C-mouse-3
> >
> > This pops up a menu; select any item from that menu.  The expected
> > result is to get the description of the menu item you selected, but
> > instead you get the prompt for "following key, mouse click, or menu
> > item" anew.
> 
> This worked fine in Emacs 25.2, FWIW.

Right, I will file a bug report for this regression.

Previous Next

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