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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  rms@gnu.org,  monnier@iro.umontreal.ca,
>   emacs-devel@gnu.org
> Date: Sun, 10 Apr 2022 15:01:56 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why is this detail important?  Conceptually, some code that runs at
> > Emacs startup will enumerate the mice and decide which one is which
> > and how to name its buttons.  Are you saying that this is impossible
> > in principle?
> 
> This is impossible in practice.  How will we know which button belongs
> to which mouse?

Again, who is "we"?  If this is about code that reads events from X,
then it certainly knows which mouse produced the button-press, by the
very nature of reading inputs from the devices.  By contrast, in Lisp,
buttons of different mice will appear with different symbols, like
mouse2-1 or mouse-15, and there's no special need to know which button
belongs to which mouse in order to process the button-press.

> What if the mice are enumerated in the wrong order?

Define "wrong order"?  IOW, how and in which situations is the order
important/significant, and on what level in Emacs should that be
known?

> We could sort the mice by some unique identifier (read: their names),
> but the user will still have to know the names of the mice, and it seems
> to me that will be very confusing.

Why will the user need to know?  And why is the user's need to know
related to how we process the events from the mouse in Lisp?

> > I think the question is rather "why do you think you _have_ to be able
> > to do the same when a second mouse is connected?"  IOW, if this second
> > mouse can be handled by existing Lisp-level infrastructure, why do we
> > need to introduce new infrastructure, and one that leaks low-level
> > information to Lisp on top of that?
> 
> I wasn't very convinced about the ability of the existing Lisp-level
> infrastructure to handle this.

Why not?

> This information isn't also very low level anymore, when many other
> programs are exposing the device information to their users and plugins.
> 
> Programs running in a browser, for example, can access the device name
> information (and also many other details that we could expose in Emacs,
> but I can't think of a use case for things such as mouse acceleration
> profiles and haptic actuators in Lisp code.)
> 
> 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.
> 
> Being based on Qt, that device information is also available to Krita
> plugins.

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.