Re: Additional cleanup around xterm-mouse

[Jared Finder via "Emacs development discussions." <emacs-devel@gnu.org>]

On 2020-11-28 8:36 am, Eli Zaretskii wrote:
>> Date: Sun, 22 Nov 2020 15:56:50 -0800
>> From: Jared Finder <jared@finder.org>
>> Cc: emacs-devel@gnu.org
>> 
>> > So I'm still asking why can't we do something like
>> >
>> >   (if xterm-mouse-mode
>> >       (read-key)
>> >     (read-event))
>> >
>> > in all the affected places that currently call read-event?
>> 
>> This can be done in all places except widget-key-sequence-read-event
>> (see below for an explanation).  Though it feels like a bad solution 
>> as
>> the info pages clearly state right now that if you want to read
>> translated events, you should use read-key, not read-event.  Mouse
>> events always could be translated because of xterm-mouse-mode, so 
>> isn't
>> this just a bug?
> 
> Maybe it is a bug, but somehow we've lived with it for a very long
> time.
> 
> Btw, my main worry is not that we will begin to use translated events
> where we formerly didn't, it's that we will use an input function
> whose code is very different, and thus some aspects of its behavior in
> various situations could very well be subtly different, thus breaking
> some use cases.  Try to compare the two functions and figure out
> whether they behave the same or not, and in what cases.  The code is
> so different that even understanding how they both receive the same
> events is non-trivial.  How does one assess risk from this change in
> cases like this one?

This makes sense to me.  I agree that read-key is likely to currently 
behave different in some situations from read-event.  Are these 
differences bugs that should be fixed or are they now features that can 
not be changed?  I ask because I feel bad about adding yet another 
difference between xterm-mouse and "native" mouse support.

I'm about 33% through analyzing read-key and have already found the 
following differences:

* read-key resets this-command-keys, read-event appends to it.
* read-key does not return switch-frame events as they happen, 
read-event does.

Are these bugs to fix?  If so perhaps an exhaustive analysis with good 
unit test coverage could address the risk here and provide a path to 
removing such a difference in the future.  I agree that in the short 
term, adding (if xterm-mouse-mode (read-key) (read-event)) is the safest 
path.

>> Note that because function keys are also affected, for this function 
>> the
>> check whether to use read-key or read-event would need to be something
>> like:
>> 
>> (if (eq window-system nil) ; This is correct on Linux and macOS, not
>> sure
>>                             ; if accurate for other platforms
>>      (read-key)
>>    (read-event))
> 
> That won't be necessary: in wid-edit.el, just replace read-event with
> read-key, and let's see how much this breaks.

Sounds good. I will modify my patch soon.

   -- MJF