Re: Additional cleanup around xterm-mouse

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 15 Nov 2020 22:29:20 -0800
> From: Jared Finder <jared@finder.org>
> Cc: 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.

Soon.

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

I don't think I follow.  All the places where you need changes are
related to handling mouse events, so why cannot it be specific to
xt-mouse?

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

Doesn't look too bad, but I don't think I have a clear idea of how you
thought to use this in those places where you need xt-mouse to be
supported?

> 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 think I like this latter alternative better.  It is slightly less
elegant, but simpler and less risky.  Can you show a draft of a patch
along those lines?

Thanks.