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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
>> Date: Sat, 09 Apr 2022 19:44:57 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > No, only for events that are specific to the device and not available
>> > in other devices.
>> 
>> But the point is that they aren't specific to the device.  The device
>> will in the general case behave like any other device (a touchpad will
>> scroll just like a mouse, and an eraser will move the pointer like any
>> other stylus), but inside specific use cases, such as precision
>> scrolling and artist-mode, they will have to behave differently.
>
> If the events are to be interpreted as usual in some situations and
> differently in others, we could have a special mode or variable to
> change the produced events only when we want that to be.
>
> Alternatively, we could always produce special kinds of events, and
> have them mapped to the same commands as the "normal" events.  For
> example, touchpad-button-1 could be mapped to the same command as
> mouse-1 in most cases, but when we want to treat those touchpad events
> specially, we could rebind them to other commands.  Similar to how we
> usually make shifted keys to invoke the same commands as unshifted
> keys, unless there's actually a binding for the shifted key.

What if the buttons we want to change are not part of a specific kind of
device?  We would then still have to expose the name of the device via
the events, like such:

  "Logitec USB Optical Mouse (2)-mouse-1"
  "Logitec USB Optical Mouse-mouse-1"

These are events from two different mice, that are otherwise identical.

> That's exactly what I was afraid of: that commands will need to care
> about devices.  Next we will have N devices for X Windows, M different
> devices for NS, Y devices for MS-Windows (some of them similar to X,
> others similar to NS), etc. -- and commands will have to dispatch on
> all those devices, right?

Not exactly.  Only commands that operate on devices by name (in which
case the user will be setting the name, see my reply to Lars), or on
devices that aren't explictly supported in `device-class' will have to
care about the window-system specific device name.

> What does it matter who personally will write the code -- it will need
> to be written, and sooner or later will find its way into the core.
> "Please accept this patch that adds the device I have here and would
> like to be able to use with Emacs, but it is not yet in the list of
> devices Emacs supports."  Sounds familiar?



> Yes, and then someone develops another compositor and provides names
> that are identical to Wayland for different devices, or different
> names for the same devices.  Each team of toolkit developers might be
> consistent with itself, but why should we believe they are consistent
> with each other?

On GNU/Linux systems the names are nearly always consistent with each
other.  On other window systems, that's why functions like
`device-class' exist: the porting process will deal with the
identification of devices.

>>        (cond ((eq draw-how 'artist-do-continously)
>> -             (artist-mouse-draw-continously ev))
>> +             (artist-mouse-draw-continously ev
>> +                                                (when (eq (device-class 
>> last-event-frame
>> +                                                                        
>> last-event-device)
>> +                                                          'eraser)
>> +                                                  'erase-char)))
>
> Do you really believe this is how Emacs's application code should be
> written?  We don't distinguish between different devices in file I/O,
> although different filesystem definitely support different features.
> Instead, where abstractions could be devised that could express
> different underlying implementations, we have such abstractions in
> Emacs.  Example: file-extended-attributes, which allow us to
> transparently support several variants of Posix-style and NTFS-style
> ACLs.  And where no such abstractions can be made or make sense, we
> have specific features supported only by some filesystems, while
> others just error out or return trivial values.  But we never-ever ask
> the filesystem what is its type and use that to change application
> code.
>
> Why should input event be any different?

File systems are not the best anology.  We have many places where we
look to see if a frame is capable of various features: displaying
grayscale, colors, true color, variable-width fonts, etc.  That would
IMHO be a closer example.  (I think shr checks `display-graphic-p'
before trying to insert images, for example.)

`device-class' also fits an area rather close to
`file-extended-attributes', I think.

> I don't need the name, I only need its number.

The number is the same, the only part that is different is the name.  We
could make the C code number them differently, but it will need to
identify that device, and that identification must be provided by the
user through Lisp.

> Yes, and where we produce the lispy keystroke event, we can convert
> that to "я", given the low-level information about the keyboard which
> emitted the key.  This way, no Lisp will need to know anything about
> the device.

The user will at least have to make the device which produced the lispy
event known to Emacs, using the language in which customizations are
written, which happens to be Lisp.

Thanks.