Re: Additional cleanup around xterm-mouse

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 15 Nov 2020 00:49:03 -0800
> From: Jared Finder via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> The first patch is very straightforward and should be trivial to review 
> and merge.

Agreed.

> I have a question about the right way to proceed with the second patch.  
> Redirecting to read-key seems like the right solution here as it is 
> "read-event but also take input-decode-map into account".  I needed to 
> make a change to read-key's implementation to make it also return button 
> down events and I saw two ways to do that.  I would like advice on which 
> way is preferred.  In the patch you can see the two options commented in 
> subr.el with Option 1 enabled by default.

Ouch, this is scary.  We have a lot of gray hair from replacing input
functions by seemingly-similar other input functions.  And on top of
that, you need changes to read-key.  These changes will affect every
"native" mouse subsystem out there, with the benefit being a single
niche mouse subsystem that is an emulator.  This sounds like not the
best way, as the risk will be shared by many important configurations
and the benefits by only one not very important one.

Can you think about a way of doing this that will affect only
xterm-mouse?  I'm okay with, for example, replacing read-event in
those cases with some new function that will call a special
xterm-mouse API when xterm-mouse is in effect, and will call
read-event otherwise.  Is something like this feasible?

Thanks.