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