emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: master 3b41141708: Expose the name of an event's input device to Lisp
Date: Sun, 10 Apr 2022 12:17:16 +0300

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]