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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 08 Apr 2022 20:35:58 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We were talking about pixel-scroll events, not about character
> > events.  If keyboard events also depend on the device, that's a
> > separate discussion.
> >
> > Let's not make the issue harder than it must be by lumping together
> > all the possible complications.
> 
> Okay, but please keep in mind that this feature was developed to work
> with all events, not just pixel-scroll events.

And you never explained in enough detail why we would need to know
about "devices" when we use other event types.  You said something
about keyboards, but I still don't understand why we would care about
the type of a keyboard.

What other kinds of input could need this information, and why?

> > It is X-specific in that it's modeled on what X exposes.
> 
> But it's also exposed by every other window system (or at least can be
> trivially synthesized from the information they expose.)

That was not yet demonstrated.  Though every system has some notion of
"input device", the information they expose could be utterly different
and not necessarily appropriate for us.  Your additions express
devices as strings, and strings don't necessarily carry any useful
information to explain the significance.  And I don't think you have
explained anywhere what aspects of the "devices" we'd want to know
about, and why.

That is why I maintain that we should first think about the
functionality we'd like to implement, and then see how best to allow
Emacs to do that, instead of designing that bottom-up from the
hardware level.

> > I'm not sure I agree with this design, sorry.  E.g., having a name for
> > a device doesn't necessarily mean we can know its type.
> 
> The type should either be inherent in the name (as on X), or the name
> should be computed to include the type (as on Wayland).  Otherwise, the
> device should just be set to the special value which says "I don't know
> what the device is".  IOW, the platform-specific code is responsible for
> ensuring that `device-class' works correctly by defining the meaning of
> "name".

I'm sorry, but this just repeats what you said already, and what I see
in the code you installed.  It doesn't get me closer to understanding
the real issues.  What is the "device type" and what is its
significance?  Are you again thinking only about regular mice vs
touchpad? if so, I already suggested an alternative way to implement
that.  If "device type" is about something more general, please
describe those more general aspects, and please try making that
description as close to exhaustive as possible, because we need to see
the general picture, not just its few isolated corners.

> > More importantly, as I already said, I'm not sure Emacs should care
> > about the type of the device that produced an event.  We need to
> > discuss what kinds of decisions a Lisp program would want to make that
> > depend on the device information, and design the information based on
> > those decisions.
> 
> I listed several: the pixel-scroll events are one such example, and
> Tetris is another.  ThinkPads come with these funny joysticks that
> normally scroll or move the mouse pointer, but inside Tetris they might
> be used to control the blocks instead.

And I suggested an alternative for dealing with these differences: new
kinds of input events.  AFAIU, going that way will completely avoid
introducing the notion of a "device" into input events.

> > I'm talking about what kind of information is exposed to the
> > application level, where we interpret the events.  That on X and maybe
> > other platforms we'll need to have low-level code that looks at the
> > device is secondary.  The current code exposes the device type/name to
> > the application level, and that is what worries me.
> 
> I don't think giving too much information to the Lisp level is that big
> of a problem, as long as its use cases are carefully evaluated, and
> recommended procedures documented.

I cannot disagree more.  This leaky abstraction will soon enough be
all over the place, just like with colors or mouse decades ago, where
Lisp programs ended up testing for X as the only condition to assume
support for mouse or colors or multiple frames.

Telling Emacs Lisp programmers not to do something is not a good way
of preventing them from doing that.  They will do what's easy and
possible, disregarding our advice as they see fit.  We will be unable
to control that efficiently, not even in core, because we cannot be
omnipresent and omniscient.

> Basically, there are two situations in which this information should be
> available: when we want some feature to behave differently based on the
> type of device, and when the user wants something to behave differently
> based on the device that is being used.

I'm still waiting for enough examples of this to even agree that it's
an issue, let alone an issue we want to solve in Emacs.

> The user could, for example, have a graphics tablet with buttons and an
> ordinary mouse connected to Emacs at the same time, and want the buttons
> on those two devices to behave differently.

We do? why?  I think we definitely DON'T.  Emacs is not a GUI toolkit,
it is a client of such toolkits.  We use toolkits because we do NOT
want to deal with device-dependent behavior, we want to use
device-independent abstractions.  If some device is unable to do
something, it will not produce events that express that functionality,
and the corresponding Emacs commands will not be invoked.  That is all
I think Emacs needs to support each input device as appropriate.

> The X Keyboard Extension (Xkb) is the component of modern X servers that
> handles keymaps, and how it couples with other server extensions is
> orthogonal to having different keyboard layouts for different physical
> keyboards implemented on the server-side.  In other words, if Emacs is
> to support such configurations, it will have to learn to understand them
> by itself.

I don't think I understand.  What would you like Emacs to support in
conjunction with Xkb, and what will Emacs have to learn about that for
it to "understand" those "configurations" (and what are those
"configurations", btw, i.e. what discerns one "configuration" from
another?).