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,  monnier@iro.umontreal.ca,
>   rms@gnu.org
> Date: Sun, 10 Apr 2022 14:09:32 +0800
> 
> 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.

Slapping a derogatory label on some idea or code doesn't provide any
real content for intelligent and flame-free discussion of the issue.
An idea doesn't magically become invalid by calling it obsolete.
Let's try to avoid such "techniques" of argument as much as possible.

As things stand, I still don't see why keeping our abstraction in this
matter somehow doesn't fit the modern input device technologies.
Please try to explain why it doesn't, by describing practical use
cases where the extant abstractions and infrastructures in Emacs
cannot handle some situations or features, whereas your proposed
design (or some alternative design) can.  So far, every example you
have given can amply be handled by the existing machinery, AFAICT.

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

Who is "we" in this context?  What level of Emacs input processing
does this "we" allude to?

My point is that the level on which devices could be important is
below the code which inserts the events into the main Emacs event
queue from which we read events as part of our main loop.  If we agree
on that, we can stop arguing about making Emacs aware of the device
types, because the only aspect that worries me in your design is that
the device type should be exposed to, known by, and actively acted
upon on much higher levels, like the commands bound to respective
input events.  That is something we should IMO try hard to avoid.

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

I don't yet understand why we _should_ know or care about that.  If a
device pretends to be a keyboard, but emits events that "normal"
keyboards cannot, we can still process such a device by pretending
those additional events are some special function keys.  Like we do
with several window-system messages already, and even with SIGUSR2
signal.  Is anything wrong with doing the same for those devices you
are talking about?  If so, what exactly is wrong and why?  Once again,
please reply by presenting specific use cases where this paradigm
cannot work well.