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

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Sat, 09 Apr 2022 18:03:20 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Well as another example, artist-mode might want to behave differently
> >> with an "eraser" pointer, removing pixels from the picture instead of
> >> adding them.
> >
> > Why cannot this be handled by producing special events that erase
> > pixels?
> 
> Because this puts us on the very inflexible path of adding special
> events for every single input device that users might want.

No, only for events that are specific to the device and not available
in other devices.

> Besides,
> the erasers send ordinary button and motion events, specifically so that
> programs can better consume input they generate without needing to
> handle a special new kind of event.

So, with your current design and implementation, what level will deal
with the device type and decide how to handle each event with the
device type in mind?  Events are bound to commands in Emacs, so does
this mean each command will need to know about the device to DTRT?

> >> That won't be very flexible, and it'll be very difficult for the user to
> >> write customizations for some new kind of device (or just a different
> >> device) without adding an entirely new kind of input event for it.  
> >
> > Please explain these two counter-arguments in more detail.  Why "not
> > very flexible" and why it will make customizations more difficult?
> 
> Let's say the developers come up with a special input device for
> entering notes.  Such a device would have a special name, and send
> either key or button presses.
> 
> Without exposing slightly low level information about the device itself
> to Lisp code, users of such a device would be forced to ask us to add an
> event specifically for that device, in order to use it in Emacs
> simultaneously with other keyboards or mice.

And what would happen instead under your design and implementation?
won't we need to add code to recognize the new device?

> The device names are guaranteed to reliably identify a device on
> GNU/Linux and other systems that run X Windows or Wayland.

I don't see how can you so sure about this.  A name is just a string.
With devices development these days, chances are what is a unique name
today will cease to be that tomorrow.

In general, I have hard time imagining that modern systems let you
access the precise and detailed device information, because (AFAIK)
modern systems typically hide this information from applications.

> > And why is that a problem?  We already interpret mouse-4 and mouse-5
> > as the wheel, so why not have mouse-8 be interpreted in some special
> > way?
> 
> Because mouse-8 is already the horizontal scroll wheel on normal mice.
> The point is, the graphics tablet buttons send the exact same events
> that ordinary mice do, but users might want them to behave differently.

How will this different behavior implemented, under your current
proposals?  Which code will deal with the device information, and how
will that eventually affect behavior?  Please show code examples if
possible.

> >> And what if the user has two ordinary mice connected, and wants one to
> >> behave differently from the other, in effect giving him an extra set of
> >> mouse buttons?
> >
> > What about it?  Why does this require to know about the device, and
> > cannot be expressed as special events?
> 
> How would you decide from which mice ordinary button events should come,
> and what others without knowing their names?

By appropriate numbering of their buttons, for example?

> > Please tell more: how do they behave differently?  If you press a key
> > that is labeled with some character, doesn't Emacs receive a keyboard
> > input event with that character?
> 
> Let's say I want to insert "завод" from the Russian keyboard.  If I
> don't manually switch the active keyboard layout on the X server-side
> when I start typing, the characters the X server sends to Emacs are in
> the US International keymap, so that becomes "pfdjl".  Similarly, if I
> want to type "factory" in English, I have to switch the active keyboard
> layout to US International, or otherwise what is sent to Emacs is
> "афсещкн".
> 
> While with the feature to retrieve device information as it is currently
> implemented, I could eventually configure the input method to be
> `russian-computer' when the device which sent the keyboard input is
> named "Innovation HID usb keyboard" instead of "AT Translated Set 2
> keyboard", the built-in US International keyboard on my laptop.

Instead of doing this on the level of input methods, why not do this
where we produce keyboard key events, by converting the keys to what
they are supposed to mean from the user's POV?  Then none of the
higher-level code will need to change, and moreover, users will be
able to use these different keyboards with input methods unrelated to
the keyboard type handling, whereas if this is done in an input
method, one cannot have another input method active at the same time
to use the characters that come from the "translation" input method.

> > We could have a keyboard-layout switch event, which would change input
> > methods automatically.  (On MS-Windows, we already have such an
> > event.)  Once again, low-level code does know about these details, and
> > that is not a problem IMO; it is exposing that to Lisp as "device"
> > that I don't like.
> 
> That would still have to expose some way to uniquely identify each
> keyboard to the user.

No, we just need a mapping from this event to an Emacs command that
will do whatever is needed for the event.  And users can customize
that command if they need.