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:

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

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

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

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

Let's skip the keyboard-related discussion for now, since they're a
somewhat special case.

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

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.

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.  Writing such a
customization would be impossible without exposing the device type
and/or name to Lisp code.

For the former situation, I think it's not a good idea to have code that
might be used by other Lisp programs to depend on the type or name of
the input device used.  But it should be fine for interactive commands
like pixel-scroll-precision to depend on that information, and perhaps
even input methods.

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

Hmm... I will try that.

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

Sorry, I misunderstood what you said there.

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

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

Thanks.