From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 29478@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
npostavs@users.sourceforge.net
Subject: bug#29478: [Patch] bug#29478: 26.0.90; `C-h k' followed by mouse clicks no longer shows down event
Date: Sat, 23 Dec 2017 11:17:26 +0000 [thread overview]
Message-ID: <20171223111726.GA6618@ACM> (raw)
In-Reply-To: <833741lr0t.fsf@gnu.org>
Hello, Eli.
On Sat, Dec 23, 2017 at 11:42:10 +0200, Eli Zaretskii wrote:
> > Date: Fri, 22 Dec 2017 22:05:49 +0000
> > Cc: drew.adams@oracle.com, 29478@debbugs.gnu.org,
> > npostavs@users.sourceforge.net
> > From: Alan Mackenzie <acm@muc.de>
> > (i) emacs-26 -Q
> > (ii) M-: (read-key-sequence "prompt: ") <CR>
> > (iii) <shift>-mouse-1
> > What happens now is the key sequence is displayed, a S-down-mouse-1
> > event, but immediately overwritten in the message area by
> > <S-mouse-1> is undefined
> > . Why? I merely asked for the key sequence. I didn't ask for it to be
> > looked up in any key maps. What is doing the translation from a
> > shift-down-mouse event to a S-click event? What is looking up this
> > down-mouse event in a key map?
> read-key-sequence itself examines the possible remapping of the
> sequence. And it seems reasonable, since how can it otherwise know
> when the sequence is complete?
> What is perhaps unexpected here (or might be a bug) is that for some
> reason the sequence is left in unread-command-events (or somewhere
> similar, perhaps in read_key_sequence_remapped?), because if I set a
> breakpoint in Fding, the backtrace from the "is undefined" message
> clearly shows it was the command loop that invoked 'undefined':
[ .... ]
Of course! read-key-sequence consumes all the events up to the
S-down-mouse-1, leaving the following S-mouse-1 in the event buffer.
This is read at the next iteration of the command loop.
> CC'ing Stefan in the hope that he could have some insights.
OK, I have a provisional fix. The problem was that the double-click-time
loop in help-read-key-sequence was discarding all events but the last
one. I have amended the loop so that _all_ these events are stored in a
list, and we then discard the most recent events till we find one with a
binding.
This patch seems to work with GPM in a Linux tty, and also in X-Windows
(I think). (It is based on the emacs-26 branch, of course.)
diff --git a/lisp/help.el b/lisp/help.el
index 212e3679da..dd1676adb0 100644
--- a/lisp/help.el
+++ b/lisp/help.el
@@ -717,7 +717,7 @@ help-read-key-sequence
(cursor-in-echo-area t)
saved-yank-menu)
(unwind-protect
- (let (key down-ev)
+ (let (key keys down-ev discarded-up)
;; If yank-menu is empty, populate it temporarily, so that
;; "Select and Paste" menu can generate a complete event.
(when (null (cdr yank-menu))
@@ -731,6 +731,7 @@ help-read-key-sequence
(or
(and no-mouse-movement
(string-match "mouse-movement" keyname))
+ (progn (push key keys) nil)
(and (string-match "\\(mouse\\|down\\|click\\|drag\\)"
keyname)
(progn
@@ -739,13 +740,31 @@ help-read-key-sequence
(sleep-for 0.01)
(while (read-event nil nil 0.01))
(not (sit-for (/ double-click-time 1000.0) t))))))))
+ ;; When we have a sequence of mouse events, discard the most
+ ;; recent ones till we find one with a binding.
+ (let ((keys-1 keys))
+ (while (and keys-1
+ (not (key-binding (car keys-1))))
+ ;; If we discard the last event, and this was a mouse
+ ;; up, remember this.
+ (if (and (eq keys-1 keys)
+ (vectorp (car keys-1))
+ (let* ((last-idx (1- (length (car keys-1))))
+ (last (aref (car keys-1) last-idx)))
+ (and (eventp last)
+ (memq 'click (event-modifiers last)))))
+ (setq discarded-up t))
+ (setq keys-1 (cdr keys-1)))
+ (if keys-1
+ (setq key (car keys-1))))
(list
key
;; If KEY is a down-event, read and include the
;; corresponding up-event. Note that there are also
;; down-events on scroll bars and mode lines: the actual
;; event then is in the second element of the vector.
- (and (vectorp key)
+ (and (not discarded-up) ; Don't attempt to ignore the up-event twice.
+ (vectorp key)
(let ((last-idx (1- (length key))))
(and (eventp (aref key last-idx))
(memq 'down (event-modifiers (aref key last-idx)))))
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2017-12-23 11:17 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-27 23:21 bug#29478: 26.0.90; `C-h k' followed by mouse clicks no longer shows down event Drew Adams
2017-11-28 1:50 ` Noam Postavsky
2017-11-28 17:11 ` Eli Zaretskii
2017-11-28 22:10 ` Alan Mackenzie
2017-11-29 0:44 ` Noam Postavsky
2017-11-29 3:36 ` Eli Zaretskii
2017-11-29 4:33 ` Drew Adams
2017-12-01 8:31 ` Eli Zaretskii
2017-12-09 17:18 ` Alan Mackenzie
2017-12-23 14:28 ` bug#29478: [Patch 2]: " Alan Mackenzie
2017-12-23 14:48 ` Andreas Schwab
2017-12-24 8:43 ` Alan Mackenzie
[not found] ` <<20171128221036.GC14868@ACM>
[not found] ` <<bbcb1d00-a728-4b5e-b65f-bd2b168c4a51@default>
[not found] ` <<83o9ni3l3i.fsf@gnu.org>
2017-12-01 15:35 ` Drew Adams
2017-12-01 16:51 ` Eli Zaretskii
2017-12-09 16:13 ` Eli Zaretskii
2017-12-09 17:23 ` Alan Mackenzie
2017-12-22 22:05 ` Alan Mackenzie
2017-12-23 9:42 ` Eli Zaretskii
2017-12-23 11:17 ` Alan Mackenzie [this message]
2017-12-23 12:41 ` bug#29478: [Patch] " Eli Zaretskii
2017-12-23 16:33 ` Stefan Monnier
2017-12-23 21:04 ` Alan Mackenzie
2017-12-24 4:55 ` Stefan Monnier
2017-12-24 5:41 ` Eli Zaretskii
2017-12-24 6:52 ` Stefan Monnier
2017-12-24 11:48 ` Alan Mackenzie
2017-12-24 15:41 ` Stefan Monnier
2017-12-30 10:50 ` Eli Zaretskii
2018-01-03 3:56 ` Stefan Monnier
2018-01-06 17:40 ` Eli Zaretskii
2018-01-07 15:31 ` bug#29478: [SUSPECTED SPAM] " Stefan Monnier
2018-01-07 17:46 ` Eli Zaretskii
2018-01-07 18:03 ` Stefan Monnier
2018-01-26 22:00 ` bug#29478: " Stefan Monnier
2018-01-26 22:37 ` Stefan Monnier
2018-01-27 8:28 ` Eli Zaretskii
2018-01-28 16:02 ` Stefan Monnier
2018-01-28 17:18 ` Eli Zaretskii
2018-01-29 21:54 ` Stefan Monnier
2018-01-30 3:23 ` Eli Zaretskii
2018-01-30 14:18 ` Stefan Monnier
2018-01-30 15:40 ` Eli Zaretskii
2018-01-30 16:59 ` Stefan Monnier
2018-01-27 7:59 ` Eli Zaretskii
2017-12-30 10:51 ` Eli Zaretskii
2017-12-30 11:32 ` Alan Mackenzie
2017-12-30 12:49 ` Eli Zaretskii
2017-12-23 16:19 ` bug#29478: " Stefan Monnier
2020-08-26 13:43 ` bug#29478: 26.0.90; " Lars Ingebrigtsen
2020-08-26 17:12 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171223111726.GA6618@ACM \
--to=acm@muc.de \
--cc=29478@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=npostavs@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).