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 19:31:28 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That suggests a different strategy: produce different input event
> > types from each such device.  That'd leave the device dependency to
> > low-level code, and let the application level deal with event kinds
> > and not with device types.  I think this is a better abstraction, if
> > it's possible/feasible.
> 
> I don't think it's feasible, especially since there are too many
> different kinds of events, and with some of them those dfferent kinds of
> events simply cannot work.  (Think single character keyboard events.)

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.

> > We have been burned by modeling the application-level features on the
> > particular X implementation and low-level details.  It took us
> > literally decades to get rid of X-specific code and features, let
> > alone API names, and move to exposing more general and more adaptable
> > APIs to applications.  I was there when this hard lesson was learned,
> > and I'd rather we didn't repeat those mistakes.
> 
> This API is not X specific at all; in contrast, an X-specific API would
> be to expose the list of device valuators and "classes", containing
> various flags.

It is X-specific in that it's modeled on what X exposes.

> When designing this feature, and why I purposely didn't design it based
> on the X concepts of device axises and classes, I worked from two
> directions: it should be possible to extract the type of a device
> (i.e. tell between a touchpad, a keyboard, a pointer, and a piano), and
> when possible (i.e. supported by the window system), it should be able
> to tell individual devices apart.  The current API achieves the first
> goal by giving each device a "name", which contains enough information
> to determine the device type, and it also achieves the second goal by
> guaranteeing that the device names are unique to each device on window
> systems which support that, such as X and Wayland.
> 
> Each window system can then define a function for `device-class', which
> returns the type of a device based on the name given to it.

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

> This feature was already implemented not just on X, but also on PGTK,
> which means it also works well with the very different input subsystems
> of Wayland and Broadway.  I also wrote the code to make it work with NS,
> but it hasn't been tested yet.

I appreciate the hard work, but I still think the design principles
should be discussed.  They should have been discussed before you
started working, for such a non-trivial new feature, but that's water
under the bridge.

> > That doesn't mean you want to know about the device, it rather means
> > you want to know the keyboard layout: an entirely different aspect,
> > and not specific to any OS.
> 
> You would still need to be able to identify the keyboard in order to
> know its keyboard layout, at least on X.

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.

> > IMNSHO, it's too bad we rush into implementing such features without
> > any discussion.  See above about the alternatives that, at least at
> > this time, seem much better to me than dragging the low-level device
> > type information to the application level, and in global stateful
> > variables on top of that.
> 
> > Which once again favors the alternative that would work by defining
> > new kinds of events.  That alternative has no compatibility issues.
> 
> IMHO we cannot simply define new kinds of wheel events that purposely
> separate touchpads from mice, or mouse-movement events which separate
> trackpoints from mice.  That would mean, from the perspective of the
> user, mice would continue to "work as before", but trackpads would not.

That's easy to fix: we can add entries in relevant maps to remap
trackpad events to mouse event by default, or when some minor mode is
in effect.

> Or a keyboard with a Greek layout would not work as it used to, while a
> keyboard with an English one would.

??? As long as Emacs reads characters, I don't see how this could
happen.  Please elaborate.

> It's also not possible to consistently give an individual keyboard a
> different keyboard layout under X, since the part of the keyboard
> extension for that only works with the obsolete version of the input
> extension, not the new one that some programs such as Emacs and most of
> the modern toolkits now support.

Sorry, I cannot understand what this means in practice.  Please tell
more.  In particular, what are those "keyboard extensions" that you
mention, and how are they relevant to the issue at hand?

> I'm sorry if I rushed things, and I'd be happy to listen to any
> suggestions you might have.

Well, I did suggest several things.