Re: Additional cleanup around xterm-mouse

[Jared Finder]

On 2020-12-02 8:53 am, Stefan Monnier wrote:
> > Subject: [PATCH] Make libraries work with xterm-mouse-mode.
>
> Could you explain (at least in the code, and ideally here as well) why
> we need this new `all-mouse-events` behavior?

I updated the function locally to look like as follows.  Let me know if 
you have further questions.

(defun read-potential-mouse-event ()
    "Read an event that might be a mouse event.

This function exists for backward compatibility in code packaged
with Emacs.  Do not call it directly in your own packages."
    ;; `xterm-mouse-mode' events must go through `read-key' as they
    ;; are decoded via `input-decode-map'.
    (if xterm-mouse-mode
        (read-key nil
                  ;; Normally `read-key' discards all mouse button
                  ;; down events.  However, we want them here.
                  t)
      (read-event)))

> `function-key-map` has very similar effects (and to a large extent, the
> downgrading of mouse-down events controlled by `all-mouse-events` could
> (I'd even say should) be implemented in `function-key-map` rather than
> via the current ad-hoc code in read-key-sequence), so I'm not very
> comfortable with treating these mouse-event-rewritings differently from
> other rewritings.

Just a few comments:

Wouldn't that require binding 2^6 * 3 * 3 * 5 = 2880 events in 
function-key-map? (2^6 for six modifier keys, 3 for down vs up vs drag, 
3 for single vs double vs triple, 5 for the mouse buttons).  Is that an 
okay overhead to add on every key press?  If not, it could instead be 
done with a default binding in function-key-map.

In both of the above cases, I believe the mapping would need to be a 
Lisp function so it can conditionally decay a triple down event to a 
double, single, or nothing depending on what is bound.

And such behavior would want a special variable (as the code is 
currently in my patch) to disable it to avoid copying all of 
function-key-map in read-key.  So I think it is fully independent of my 
current patch.

> The other question is why you made `all-mouse-events` an argument to
> `read-key` but not to `read-key-sequence` (where you pass the info via
> a dynamically-scoped var instead)?

I did this to create an API for read-key but not for read-key-sequence.  
Any package that wants to read down mouse events and work with 
xterm-mouse should call (read-key nil t).  I didn't want to create a way 
to do the same think for read-key-sequence at I could not think of a use 
case.  The special variable is named inhibit--unbound-mouse-fallback to 
indicate it is private and could change or be removed in the future.

  -- MJF