Re: Additional cleanup around xterm-mouse

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

On 2020-12-03 6:45 am, Stefan Monnier wrote:
> 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?

I want no mouse event to get dropped (drag events also get dropped, 
right?) and no mouse events to get degraded to simpler forms.  In 
summary, I want mouse events to get returned unprocessed, as if from 
read-event, but with input-decode-map applied.

The alternative I presented further up in the thread was to apply 
input-decode-map manually to successive calls to read-event.  I got this 
working, though it sounded like modifying read-key was preferred earlier 
in this thread.

For context, here's the alternative:

(defun read-decoded-key ()
   "Read a single key, as if by `read-key'.

Unlike `read-key', this does not call `read-key-sequence' and
instead has a bare-bones implementation of its functionality.  In
particular, it applies `input-decode-map' but does not apply
`local-function-key-map' or `input-translation-map'."
   (let* ((keys '())
          (decoder input-decode-map)
          (echo-keystrokes 0)
          (timer (run-with-idle-timer
                  read-key-delay t
                  (lambda ()
                    (unless (null keys)
                      (throw 'read-decoded-key nil)))))
          result)
     (catch 'read-decoded-key
       (unwind-protect
           (while t
             (let ((next-key (read-event)))
               (push next-key keys)
               (setq decoder (lookup-key decoder (vector next-key))))
             (when (pcase decoder
                     ;; A direct decoding (common for function keys)
                     ((pred arrayp)
                      (setq result decoder))

                     ;; A function that does decoding (like for
                     ;; `xterm-mouse-mode')
                     ((pred functionp)
                      (setq result (funcall decoder nil))))
               (if (zerop (length result))
                   ;; The decoding is an empty vector to say "continue
                   ;; reading".  This happens when the key would be
                   ;; mouse-movement but `track-mouse' is nil.
                   (setq keys '()
                         decoder input-decode-map)
                 (throw 'read-decoded-key nil))))
         (cancel-timer timer)))

     ;; If no decoding, the accumulated keys are the result.
     (or result (vconcat (nreverse keys)))))

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

Makes sense.  I think the easiest way to do this would be to allow 
keymaps to have multiple conditional fallbacks.  Perhaps allow a binding 
in a keymap to be a hook that runs via 
`run-hook-with-args-until-success'?  It's a slight generalization of the 
current logic which allows functions.

Technically this can be done now with just a layer of indirection on the 
[t] binding in a keymap.

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

One way to do this would be to add new behavior if DONT-DOWNCASE-LAST is 
a list.  In other words, if DONT-DOWNCASE-LAST is non-nil and not a 
list, existing behavior.  But if DONT-DOWNCASE-LAST is a list, we can 
look at the members of the list to determine what to do.  This is a 
slight change in existing behavior, but it is very unlikely to break 
anything.

   -- MJF