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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

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

[...]

> 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 only way to have this system become remotely predictable is for the
button assignment to follow some logical order, such as the alphabetical
order of the names of the mice.  For example, the mouse named "ABC"
might get assigned the buttons 1 to 14, the mouse named "ABD" 15 to 29,
and the mouse named "BDC" 30 to 44.

But that still doesn't work very well.  If another mouse named "BAA" is
attached to the system, then it will get the buttons 30 to 44, and "BDC"
will get buttons 45 to 59, and any bindings that were made to buttons on
"BDC" will now be for the wrong mouse.

> and on what level in Emacs should that be known?

The code which will assign button numbers to each mouse, if it's
implemented that way.

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

Because the user will want the buttons from different mice to behave
differently, and that will be a customization done in Lisp.

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

Thanks.