From: Eli Zaretskii <eliz@gnu.org>
To: Po Lu <luangruo@yahoo.com>
Cc: larsi@gnus.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
rms@gnu.org
Subject: Re: master 3b41141708: Expose the name of an event's input device to Lisp
Date: Sun, 10 Apr 2022 11:28:52 +0300 [thread overview]
Message-ID: <83r165735n.fsf@gnu.org> (raw)
In-Reply-To: <875ynhe6mx.fsf@yahoo.com> (message from Po Lu on Sun, 10 Apr 2022 15:31:50 +0800)
> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org, monnier@iro.umontreal.ca, rms@gnu.org,
> emacs-devel@gnu.org
> Date: Sun, 10 Apr 2022 15:31:50 +0800
>
> > I don't yet understand why we _should_ know or care about that. If a
> > device pretends to be a keyboard, but emits events that "normal"
> > keyboards cannot, we can still process such a device by pretending
> > those additional events are some special function keys. Like we do
> > with several window-system messages already, and even with SIGUSR2
> > signal. Is anything wrong with doing the same for those devices you
> > are talking about? If so, what exactly is wrong and why? Once again,
> > please reply by presenting specific use cases where this paradigm
> > cannot work well.
>
> They emit the same events that "normal" keyboards do. The foot pedal
> for example will insert "b" just the same as a "normal" keyboard will.
>
> If you open a text editor window and press the foot pedal, the letter
> "b" is inserted. If you turn on "xinput test-xi2" and press the foot
> pedal, you will probably get something like this:
>
> EVENT type 3 (KeyRelease)
> device: 3 (10) <----- this is the device ID of the foot pedal
> detail: 56 <--------- this is the keycode corresponding to the keysym "b"
> flags:
> root: 996.00/568.00
> event: 136.00/94.00
> buttons:
> modifiers: locked 0 latched 0 base 0 effective: 0
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x79a event 0x4c00001 child 0x0
>
> And if you press "b" on your keyboard, you get the same thing:
>
> EVENT type 3 (KeyRelease)
> device: 3 (4) <------ this is the device ID of the "normal" keyboard
> detail: 56 <--------- this is the keycode corresponding to the keysym "b"
> flags:
> root: 996.00/568.00
> event: 136.00/94.00
> buttons:
> modifiers: locked 0 latched 0 base 0 effective: 0
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x79a event 0x4c00001 child 0x0
>
> Since device IDs are not in any particular order or guaranteed to always
> be the same for each device, we use the name of the device to identify
> devices instead. The relationship is similar to that of file
> descriptors and file names.
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?
> But presumably the program for which the foot pedal was designed for
> presents the user with a dropdown from which the device that is actually
> the foot pedal is chosen. That way, if an input with the character "b"
> is registered and comes from the foot pedal, it treats that as a press
> of the pedal. Otherwise, it treats it as the user pressing the
> character "b" on the keyboard.
>
> I hope this explanation makes things clearer.
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.
next prev parent reply other threads:[~2022-04-10 8:28 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <164933858147.29834.15050766441005536059@vcs2.savannah.gnu.org>
[not found] ` <20220407133623.9C209C009A8@vcs2.savannah.gnu.org>
2022-04-07 14:05 ` master 3b41141708: Expose the name of an event's input device to Lisp Stefan Monnier
2022-04-07 23:31 ` Po Lu
2022-04-07 23:41 ` Stefan Monnier
2022-04-08 0:07 ` Po Lu
2022-04-08 6:02 ` Eli Zaretskii
2022-04-08 6:08 ` Po Lu
2022-04-08 6:26 ` Eli Zaretskii
2022-04-08 7:36 ` Po Lu
2022-04-08 11:12 ` Eli Zaretskii
2022-04-08 11:31 ` Po Lu
2022-04-08 12:12 ` Eli Zaretskii
2022-04-08 12:35 ` Po Lu
2022-04-09 6:48 ` Eli Zaretskii
2022-04-09 9:06 ` Po Lu
2022-04-09 9:09 ` Lars Ingebrigtsen
2022-04-09 9:30 ` Eli Zaretskii
2022-04-09 10:03 ` Po Lu
2022-04-09 11:03 ` Eli Zaretskii
2022-04-09 11:44 ` Po Lu
2022-04-09 14:04 ` Eli Zaretskii
2022-04-09 16:33 ` Stefan Monnier
2022-04-09 16:41 ` Lars Ingebrigtsen
2022-04-09 17:06 ` Eli Zaretskii
2022-04-09 17:16 ` Eli Zaretskii
2022-04-09 17:52 ` Brian Cully
2022-04-09 19:18 ` Eli Zaretskii
2022-04-10 0:54 ` Po Lu
2022-04-10 1:46 ` Brian Cully
2022-04-10 2:11 ` Po Lu
2022-04-10 2:45 ` Brian Cully
2022-04-10 3:30 ` Po Lu
2022-04-10 0:37 ` Po Lu
2022-04-10 5:49 ` Eli Zaretskii
2022-04-10 6:09 ` Po Lu
2022-04-10 6:44 ` Eli Zaretskii
2022-04-10 7:31 ` Po Lu
2022-04-10 8:28 ` Eli Zaretskii [this message]
2022-04-10 8:50 ` Po Lu
2022-04-10 9:17 ` Eli Zaretskii
2022-04-10 9:25 ` Po Lu
2022-04-10 11:15 ` Po Lu
2022-04-10 15:16 ` Stefan Monnier
2022-04-11 1:02 ` Po Lu
2022-04-10 11:46 ` Lars Ingebrigtsen
2022-04-10 11:41 ` Lars Ingebrigtsen
2022-04-10 0:48 ` Po Lu
2022-04-10 6:04 ` Eli Zaretskii
2022-04-10 6:17 ` Po Lu
2022-04-10 6:49 ` Eli Zaretskii
2022-04-10 7:01 ` Po Lu
2022-04-10 8:24 ` Eli Zaretskii
2022-04-10 8:42 ` Po Lu
2022-04-10 9:13 ` Eli Zaretskii
2022-04-10 12:51 ` Brian Cully
2022-04-10 13:21 ` Po Lu
2022-04-10 18:08 ` Brian Cully
2022-04-11 0:58 ` Po Lu
2022-04-11 1:08 ` Brian Cully
2022-04-11 2:00 ` Po Lu
2022-04-11 2:03 ` Po Lu
2022-04-11 2:21 ` Brian Cully
2022-04-11 3:12 ` Po Lu
2022-04-11 4:11 ` Brian Cully
2022-04-11 5:20 ` Po Lu
2022-04-11 11:33 ` Brian Cully
2022-04-11 14:09 ` Po Lu
2022-04-11 16:26 ` Brian Cully
2022-04-11 10:10 ` Lars Ingebrigtsen
2022-04-10 12:44 ` Brian Cully
2022-04-10 13:14 ` Po Lu
2022-04-08 14:27 ` Stefan Monnier
2022-04-09 0:24 ` Po Lu
2022-04-09 2:52 ` Stefan Monnier
2022-04-09 3:17 ` Po Lu
2022-04-09 13:31 ` Stefan Monnier
2022-04-09 13:37 ` Po Lu
2022-04-09 14:20 ` Stefan Monnier
2022-04-10 0:58 ` Po Lu
2022-04-09 14:31 ` Eli Zaretskii
2022-04-10 0:56 ` Po Lu
2022-04-10 6:11 ` Eli Zaretskii
2022-04-10 6:23 ` Po Lu
2022-04-10 6:52 ` Eli Zaretskii
2022-04-10 7:37 ` Po Lu
2022-04-10 8:12 ` Eli Zaretskii
2022-04-09 6:22 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83r165735n.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
--cc=luangruo@yahoo.com \
--cc=monnier@iro.umontreal.ca \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.