Re: master 3b41141708: Expose the name of an event's input device to Lisp

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Richard Stallman <rms@gnu.org>,  Lars Ingebrigtsen <larsi@gnus.org>,
>   monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Sun, 10 Apr 2022 08:48:48 +0800
> 
> > Alternatively, we could always produce special kinds of events, and
> > have them mapped to the same commands as the "normal" events.  For
> > example, touchpad-button-1 could be mapped to the same command as
> > mouse-1 in most cases, but when we want to treat those touchpad events
> > specially, we could rebind them to other commands.  Similar to how we
> > usually make shifted keys to invoke the same commands as unshifted
> > keys, unless there's actually a binding for the shifted key.
> 
> What if the buttons we want to change are not part of a specific kind of
> device?

Then the events emitted by those buttons which are not part of the
device will not be emitted.

Or maybe I misunderstand what you have in mind when you say "the
buttons we want to change are not part of the device".

> We would then still have to expose the name of the device via
> the events, like such:
> 
>   "Logitec USB Optical Mouse (2)-mouse-1"
>   "Logitec USB Optical Mouse-mouse-1"

If these events are different, they should have different symbols,
yes.  How is this different from, say, mouse-6, which only appears
when you have a mouse with 6 or more buttons, although commands can be
bound to mouse-6 even if such a mouse isn't available?

> These are events from two different mice, that are otherwise identical.

We've been through this: the second mouse should have its buttons
numbered starting from some number N to distinguish it from the first.
For example, N could be 11, so the buttons are mouse-11, mouse-12,
etc.

> File systems are not the best anology.  We have many places where we
> look to see if a frame is capable of various features: displaying
> grayscale, colors, true color, variable-width fonts, etc.  That would
> IMHO be a closer example.  (I think shr checks `display-graphic-p'
> before trying to insert images, for example.)

Display capabilities are tested as preconditions for producing some
fancy effect on display, not for dispatch on input events.  If we
don't test the display for some capability, trying to produce the
related display effect is likely to signal an error, which is not
useful.

Besides, even if the display-capability analogy is actually an
argument against your design: we test generic capabilities, not the
names of the display terminal on which Emacs shows its frames.

Applied to input events, the test for the capability is done where we
produce the Lispy events: if a device doesn't have some capabilities,
the corresponding events are not produced.  So the test of the
capabilities is in this case implicit from the Lisp POV; the Lisp
level is always ready to receive all the events Emacs knows about.

> > Yes, and where we produce the lispy keystroke event, we can convert
> > that to "я", given the low-level information about the keyboard which
> > emitted the key.  This way, no Lisp will need to know anything about
> > the device.
> 
> The user will at least have to make the device which produced the lispy
> event known to Emacs, using the language in which customizations are
> written, which happens to be Lisp.

That is a separate issue, not the one I was talking about.  If there
needs to be some Lisp executed, once, when the (second) keyboard is
attached to Emacs, or when we switch to another type of keyboard, and
if that cannot be done automatically (e.g., by Emacs listening to some
special system event or polling some port), then so be it.  But from
that point onwards, the key input on the Lisp level doesn't need to
know about the keyboard devices, perhaps not even that there's more
than one keyboard.