bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks

[Andy Moreton]

On Mon 30 Jul 2018, Noam Postavsky wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> >> > If we want this change on emacs-26, we should carefully audit all the
>>> >> > other users of rmc.el
>>> 
>>> What should we check for though?
>>
>> Anything that read-event handles differently from read-char.  Maybe a
>> good starting point is to compile a list of the differences in
>> behavior between the two.
>
> Looking at the implementation, they both delegate to
> read_filtered_event, but read-char passes 1 for the first three args,
> where read-event passes 0.
>
>    If NO_SWITCH_FRAME, switch-frame events are stashed
>    until we get a character we like, and then stuffed into
>    unread_switch_frame.
>
>    If ASCII_REQUIRED, check function key events to see
>    if the unmodified version of the symbol has a Qascii_character
>    property, and use that character, if present.
>
>    If ERROR_NONASCII, signal an error if the input we
>    get isn't an ASCII character with modifiers.  If it's false but
>    ASCII_REQUIRED is true, just re-read until we get an ASCII
>    character.

So perhaps this `read-char' to `read-event' change will result in different
frame switching behaviour. I'm not sure how to test that though.

> Another possibility is to use read-char-exclusive which only changes
> ERROR_NON_ASCII to 0.  The downside is that when there are mouse clicks
> it prints the events into the minibuffer, covering the prompt (but
> typing "?"  still works to restore the prompt).

AS you have done, I read the implementation and tried a patch using
`read-char-exclusive'. The result is unusable as the printed events
obscure the original question.

The proper long term fix for this is to make read-multiple-choice use a
dedicated buffer rather than the minibuffer, and give better visibility
when more than one question is asked in succession. Perhaps also some
way to stop the echo area from obscuring the minibuffer ?

    AndyM