Re: Additional cleanup around xterm-mouse

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

On 2020-11-15 10:29 pm, Jared Finder wrote:
> 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>).

I meant to say here "This **works** w/o changes to read key, but with a 
behavior change." Sorry for any confusion caused.

   -- MJF