Re: Additional cleanup around xterm-mouse

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

On 2020-11-15 10:11 am, Eli Zaretskii wrote:
>> 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.

Great. It's completely independent of the other change, feel free to 
merge at any time.

>> I have a question about the right way to proceed with the second 
>> patch.
>> [...]
> 
> 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?

I was a little nervous about changing read-key's default behavior too.  
Happy to explore other options. :)

Creating such an alternative function doesn't appear too bad if you're 
okay with having the same run-with-idle-timer pattern that read-key 
uses.  I do not think it can be xterm specific as it needs to apply all 
of input-decode-map to be able to return function keys such as [f1] on a 
native Linux term or an xterm.  (This is important for 
widget-key-sequence-read-event.)  However, it can avoid the rest of the 
complexity of read-key-sequence.  I'm imagining something like this 
(untested code follows, just wanted to give a flavor of it):

(defun read-decoded-key ()  ; I'd love a better name here.
   ;; Start of code like read-key's code.
   (let ((keys '())
         (timer (run-with-idle-timer
                 read-key-delay t
                 (lambda ()
                   (unless (null keys)
                     (throw 'read-key nil))))))
     (unwind-protect
         (while t (push (read-event) keys))
       (cancel-timer timer))

     ;; Start of new stuff: Apply transformations from input-decode-map.
     (do-stuff)

     (vconcat (nreverse keys))))

As you can see, this avoids all the complexity around managing the 
different keymaps that read-key currently has since it calls 
read-key-sequence.


An alternative is to just use read-key as is in most cases and make my 
change a parameter / special variable.  Most of my patch's changes work 
fine with the existing behavior of read-key.  Only the following changes 
do not:

* lisp/vc/ediff-wind.el (ediff-get-window-by-clicking)
==> As coded, expects the first mouse event returned by read-event to be 
a down-mouse-X event, which it then follows by another call to 
read-event to get the mouse-X event.  It could be easily changed to only 
look for the up event.

* lisp/strokes.el (strokes-read-stroke, strokes-read-complex-stroke)
* lisp/textmodes/artist.el (artist-mode-draw-poly)
==> These both expect to detect a mix of down-mouse-X and mouse-X 
events.

* lisp/wid-edit.el (widget-key-sequence-read-event)
==> This w/o changes to read-key, but with a behavior change.  With no 
changes to read-key it returns just a single up event.  Currently on 
other environments you get both a down and up event (e.g. <down-mouse-1> 
<mouse-1>).

   -- MJF