Re: Additional cleanup around xterm-mouse

[Stefan Monnier <monnier@iro.umontreal.ca>]

Jared Finder [2020-12-02 21:46:53] wrote:

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

That doesn't say what this function should do with non-mouse events, so
it makes it hard to decide what its behavior should be.

OK, so what you specifically need is for down events not to be
dropped, right?


>> `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?

Yes, but that's only because of the limited form available in keymaps.
To make it practical, we'd need to add "computed keymaps".  This is
a long-standing desire of mine, which would be useful in various
circumstances (and should make it possible to remove a lot of ad-hoc
rewritings in read_key_sequence).

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

Yes.  My point is just that a functionally "don't discard mouse-events"
is weird in a function which is not specifically about mouse events.
It naturally leads to "don't down case events", "don't remap `tab` to
TAB", etc...
There has to be a more general underlying principle.

Maybe we could (re)use the DONT-DOWNCASE-LAST arg of `read-key-sequence`
for that?  This would mean no change in `read-key` but a change in
`read-key-sequence` instead (and hence further-reaching consequences).

Or maybe an option to `read-key` to disable all
function-key-map-like remappings (i.e. remappings which are only applied
if there's no binding for that key-sequence)?


        Stefan