[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.
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, (continued)
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/09
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Eli Zaretskii, 2022/04/10
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/10
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Eli Zaretskii, 2022/04/10
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/10
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Eli Zaretskii, 2022/04/10
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/10
- Re: master 3b41141708: Expose the name of an event's input device to Lisp,
Eli Zaretskii <=
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/10
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/10
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Stefan Monnier, 2022/04/10
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/10
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Lars Ingebrigtsen, 2022/04/10
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Lars Ingebrigtsen, 2022/04/10
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/09
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Eli Zaretskii, 2022/04/10
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/10
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Eli Zaretskii, 2022/04/10