Re: Additional cleanup around xterm-mouse

[Eli Zaretskii <eliz@gnu.org>]

> 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?

> By the way, the info text I'm referring to is the following excerpt from 
> (elisp)Top > Command Loop > Reading Input > Reading One Event.
> 
>     We emphasize that, unlike ‘read-key-sequence’, the functions
> ‘read-event’, ‘read-char’, and ‘read-char-exclusive’ do not perform the
> translations described in Translation Keymaps.  If you wish to
> read a single key taking these translations into account, use the
> function ‘read-key’:

That's okay.  We frequently tell "do as I say, not as I do", and
there's nothing wrong with that: the ELisp manual is primarily a text
for Lisp programmers, not a faithful description of the Emacs design
and implementation (although it does include some of the latter).

> Note: the wid-edit.el change is also pretty major and where I first 
> noticed this.  Without some fix there, interaction with widgets in 
> Customize buffers with an xterm mouse will cause infinite loops that 
> only C-g can escape.

I'm okay with making such a change in wid-edit.el, mainly because that
case is unlikely to hit the problems I worry about, and even if it
does, it's just one package.

> 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.

Thanks.