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

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org,  monnier@iro.umontreal.ca,
>   rms@gnu.org
> Date: Sun, 10 Apr 2022 16:50:40 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > My point is: Emacs should use the information about the device where
> > it generates the Lispy event.  At that point, we should generate a
> > different Lispy event for a device whose events we want to handle
> > differently.  On the higher levels, the device information should not
> > be necessary for processing those Lispy events.
> >
> > How does my point above contradict the data you show about these two
> > devices?
> 
> > I hope my response above explains why I think the need to know the
> > device info can and should stop at the level where we produce the
> > Lispy event objects.
> 
> Hmm... how about a variable `device-function-key-alist', which maps
> device names and classes to the corresponding function key?

The low-level code which generates Lispy events can, of course, use
some Lisp data structures, including user-defined data structures.

> The code to read events could then be changed to add such a function key
> when an event is received for the suitable type of device.
> 
> For example, pixel-scroll-precision-mode could add ((class mouse)
> . coarse-mouse) to that list, which would make events coming from a
> mouse report themselves with the fake function key `coarse-mouse'.

Yes, but what does the "class" part in "class mouse" signify?  Why not
just "mouse"?

> Then, the command to scroll with interpolation could be bound to
> [coarse-mouse wheel-down].
> 
> Or Lars could specify ("Name of footpad device" . footpad), and bind the
> appropriate commands to [footpad a], [footpad b] and so on?
> 
> WDYT?

That's fine, but such a data structure, and/or the API for setting it,
should be designed to be "safe", in that users cannot too easily shoot
themselves in the foot by making mistakes in their data.