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 08:49:07 +0300

> From: Po Lu <luangruo@yahoo.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  Eli Zaretskii
>  <eliz@gnu.org>,  Richard Stallman <rms@gnu.org>,  emacs-devel@gnu.org
> Date: Sun, 10 Apr 2022 08:37:31 +0800
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > So if I could somehow say
> >
> > (keymap-set global-mode-map "[device footpad]-b" 'do-something)
> >
> > that would be ideal.
> 
> Oh yes, that would be good as well.  We could have the ability to bind
> keys to individual devices.

I think the usual Emacs abstraction centers on the events, not on
devices that emitted them.  So we should be able to have devices emit
events regardless of the device type/nature/name, and then the usual
Emacs machinery of binding commands to key sequence will do the rest,
and will do it according to user expectations.

> I could imagine a different API that didn't put the device name into the
> name of the key

The key doesn't have to be a device name, it should rather describe
the general type of the event/functionality.  For example, all the
devices that have foot pedals could emit events that begin with the
same pseudo-function key 'foot-pedal'.  Even if the device is called
something else, and even if the device is simulated by some software
that takes input from the keyboard or the mouse.

> And the "name of footpad" can reasonably be system dependent

It shouldn't be.

> since the user will be making such a customization

Users cannot customize the low-level layers of event production in
Emacs, that level must be coded by us.  We shouldn't try aiming for
this goal, because it is basically unattainable, certainly as long as
we use the window-system messages as triggers for producing events
eventually exposed to Lisp.



reply via email to

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