Subject: bug#23980: closed (Re: bug#23980: 25.0.95; Events put in `unread-command-events' can be wrongly handled)

From: [email-masked] (GNU bug Tracking System)
Date: Sun, 19 Nov 2017 09:40:02 +0000

Your bug report

#23980: 25.0.95; Events put in `unread-command-events' can be wrongly handled

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
23980: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23980
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#23980: 25.0.95; Events put in `unread-command-events' can be wrongly handled
From: Chris Feng <[email-masked]>
To: [email-masked]
Date: Sun, 19 Nov 2017 17:39:28 +0800
List-Id: <debbugs-submit.debbugs.gnu.org>

The bug was fixed by 1f3f4b1296.

Subject: 25.0.95; Events put in `unread-command-events' can be wrongly handled
From: Chris Feng <[email-masked]>
To: [email-masked]
Date: Thu, 14 Jul 2016 22:03:34 +0800
List-Id: <debbugs-submit.debbugs.gnu.org>

I encountered a bug in the command loop that when I put an event of the
form (t . EVENT) into `unread-command-events', there is a chance the
event won't get recognized with the message "<t> is undefined".
I did a bit research and found that in keyboard.c `read_char' calls
`read_decoded_event_from_main_queue' (which in turn calls
`read_event_from_main_queue' and `kbd_buffer_get_event') but does not
check if the returned event is from `Vunread_command_events'.
The problem in `read_char' can be demonstrated by the following form:

  (progn
    (run-with-timer 1 nil (lambda () (push '(t . 1) unread-command-events)))
    (read-event nil nil 2))

    => '(t . 1)

There is actually another related issue, that for an event returned by
`read_decoded_event_from_main_queue' other than the form (t . EVENT), we
can't tell whether it's from `Vunread_command_events' or not.
If it is, then we should not put it into `this_command_keys'.

Any ideas on how to fix these?