emacs-devel
[Top][All Lists]
Advanced

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

Re: Physical keyboard events


From: Po Lu
Subject: Re: Physical keyboard events
Date: Mon, 04 Nov 2024 22:37:44 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think I agree with you.  I think I'm with Cecilio here.
> Physical key events means that Emacs doesn't perform any conversions,
> it leaves that to the Lisp program which receives such events.  E.g.,
> when I press the Alt key, I expect to see an event of pressing the Alt
> key, not a (non-existent) Meta.  And if I press the Right Alt key, I
> expect to see AltGr, not Alt and not Meta.

The issue is that X does not attach enough significance to keysyms
reliably to tell AltGr from Alt, or the like, with a keysym alone.  A
keysym is just that--a symbol printed on a key cap, and it is up to
users to bind these keys to modifier bits, all of which but Shift, Caps
Lock, and Ctrl are completely nondescript and for client programs such
as Emacs to interpret.

E.g., AltGr could be configured on the OS level to serve as a level 3
shift key, as it typically does, or as an entirely different modifier,
without affecting the keysym (XK_Alt_R _or_ XK_ISO_Level3_Shift) or even
the modifier bit (on my system, Mod5) generated.  Likewise, Caps Lock
could be configured to Control while continuing to be reported as
XK_Caps_Lock.

Emacs already tries to establish a sensible relationship between
modifier bits and Emacs modifiers, and clearly, the reasonable way
forward is to write a small quantity of code to deduce the modifier bits
produced by a keysym, and reuse the existing mechanism to report a
modifier that users will expect, instead of engineering a different
mechanism for the purposes of reporting modifier activation and
deactivation, or, as Cecilio's patch currently does, reporting keysyms
totally independent of the modifiers actually bound to their keys.

>> BTW, if the intention is to forward just modifier key events to Lisp,
>> don't let's refer to them as "physical keyboard events", but in more
>> specific terms.
>
> Yes, I think the idea is to generate modifier key events and expose
> them to Lisp.  What is more specific than "physical keyboard events"?

"Modifier activation and release events", perhaps?


reply via email to

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