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 15:36:05 +0800
> 
> > What for?  Why do we care in Emacs which device generated a scroll
> > event?  Emacs was always transparent regarding that, and did the same
> > regardless of the particular device which caused the event.  Why do we
> > suddenly need to distinguish between them?  This could add complexity
> > to Emacs's application level that we don't particularly want.  So if
> > we do add this, it had better be a very good reason.
> 
> Basically, precision scrolling comes in two forms: the first immediately
> scrolls the screen by the deltas given, while the second "animates" a
> scroll from the original position to the position with the deltas.
> 
> All the major programs and toolkits today seem to be converging on using
> the first strategy for touchpad devices and tablets, and the second for
> mice.

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.

> > Most input events nowadays come from the window-system, which
> > typically hides the device level from the application.  For example,
> > there are programs that allow you to inject mouse events by typing on
> > the keyboard, and vice versa.  There are also programs that inject
> > keyboard events programmatically.  Etc. etc.  Why would we want to
> > know or care exactly what device generated an event?
> 
> That's not hidden under X Windows and GTK, where we see that many other
> applications are relying on that information as well.  For example,
> Firefox-based browsers and WebKit both use it to determine which form of
> "precise scrolling" strategy to use.

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.

Let's see from the get-go how this kind of functionality can be
expressed in device-independent and window-system independent ways,
and design the APIs accordingly.  For that, we need to define what are
the aspects that applications would like to know about when dealing
with these input events, and then see how this could be abstracted or
generalized to any input system we support now and can envision to
support in the future.  E.g., what about GPM and xt-mouse on TTYs?
what about window-systems that aren't based on X? etc. etc.

> NS doesn't expose the device name, but it does expose the kind of device
> which generated the event.  On macOS, GTK uses that information to
> compute an artificial device name, which works well enough.

Works very well for whom? for GTK?  That's not a criterion I'd expect
us to apply here.  We need to do what will work well for Emacs.

> > The question is why it is useful for Emacs to know which keyboard
> > device generated a key sequence.
> 
> I can imagine an input method behaving differently depending on which
> keyboard is being used, since individual keyboards can have different
> layouts convenient for typing in separate languages.

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.

> > In any case, if we do agree to have this information in Emacs, the
> > definition of a "device" should be abstract enough to allow its
> > implementation on systems other than X.
> 
> It has already been implemented on Wayland, and the implementation on NS
> is waiting for a machine on which it can be tested.

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.

> > And then I will ask a question similar to that Stefan asked: why not
> > make the device part of event object we have on the event queue?
> 
> It's already part of the `struct input_event', but compatibility
> requirements prevent it from being made part of the Lisp events itself,
> so we store it as one of the last-event-* variables instead.

Which once again favors the alternative that would work by defining
new kinds of events.  That alternative has no compatibility issues.