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: larsi@gnus.org,  emacs-devel@gnu.org,  rms@gnu.org,
>   monnier@iro.umontreal.ca
> Date: Sun, 10 Apr 2022 16:42:36 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Define "wrong order"?  IOW, how and in which situations is the order
> > important/significant,
> 
> Because the user doesn't know what lispy button a given button on a
> certain mouse corresponds to.  `mouse-15', for example, could be the
> first button of any mouse connected to the system, assuming each mouse
> has 14 buttons.

The user doesn't care about numbering, the user only cares that when
he presses a button on a certain mouse, the command that gets invoked
is the command bound to that button of that mouse.

Are you saying that querying the system about the connected mice will
enumerate them in random order every time the system is restarted?  If
the order is the same, then the first time a mouse is connected, the
user will see the symbols of the buttons of that mouse, and can then
do the customizations accordingly.  (The same initial adjustment will
have to happen with your device-name idea, because the user won't know
the name until the mouse is connected and Emacs tells him what is the
name of the mouse.)

If the order of enumerating the devices is unpredictable each time the
system starts, we could have some data structure that maps device IDs
to symbols of events.  Such a data structure should be designed to be
as safe as possible, though, so users couldn't shoot themselves in the
foot by making spelling mistakes there.

> > This is orthogonal.  Being able to show the user the details of
> > connected input devices is unrelated to how the input events are
> > processed.  The information comes from the same source, of course, but
> > the code which produces input events can (and IMO should) consult this
> > information at a low enough level, so that interpreting the events in
> > Lisp and binding them to commands should not need any device
> > information to be known by the application code.  The application code
> > should only use the Lispy input event, and that event should already
> > include all the information required for processing it.
> 
> Those programs don't just show the details to the user, they expose
> those details to application code, in the hopes that the application
> code will allow the code to behave appropriately, and the user to
> customise the behavior based on those details.

The "show the details to the user" part came from your remark:

> This information isn't also very low level anymore, when many other
> programs are exposing the device information to their users and plugins.
> [...]
> The KDE paint program Krita apparently has the ability to configure
> individual tablet devices to behave differently.  The user is presented
> the device name and a set of different behaviors for that device.

But anyway, It is okay for Emacs code to use this information provided
that we do it on a low enough level.