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

[Po Lu <luangruo@yahoo.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> I think the usual Emacs abstraction centers on the events, not on
> devices that emitted them.  So we should be able to have devices emit
> events regardless of the device type/nature/name, and then the usual
> Emacs machinery of binding commands to key sequence will do the rest,
> and will do it according to user expectations.

It seems to me that abstraction was built around text terminals and
legacy X windows behavior, which changed with the wide adoption of
multiple instances of different kinds of input devices in X and
elsewhere.

> The key doesn't have to be a device name, it should rather describe
> the general type of the event/functionality.  For example, all the
> devices that have foot pedals could emit events that begin with the
> same pseudo-function key 'foot-pedal'.  Even if the device is called
> something else, and even if the device is simulated by some software
> that takes input from the keyboard or the mouse.

But we cannot determine whether a given device is a foot pedal without
the help of the user.  It's not one of the types of devices whose naming
is well established (see the list in the doc string of `device-class'.)

That fact doesn't apply to all devices, though, so why not have both
options?

There could be a "puck" or "touchpad" prefix for the devices that we can
classify, and a way to name the devices (or assign prefixes to those
devices) that we can not.

> Users cannot customize the low-level layers of event production in
> Emacs, that level must be coded by us.  We shouldn't try aiming for
> this goal, because it is basically unattainable, certainly as long as
> we use the window-system messages as triggers for producing events
> eventually exposed to Lisp.

Then we won't be able to know what a foot pedal is, because presumably
foot pedals just name itself something we cannot guess, like "USB USB
Keyboard (1)" or "FlexMatrix HID Keyboard Controller", since it's
pretending to be a keyboard.

The user must determine that information from the relevant tools on his
own system, i.e. by watching the output of the `xinput list' command.

Thanks.