Re: Physical keyboard events

[Cecilio Pardo <cpardo@imayhem.com>]

On 05/11/2024 2:31, Po Lu wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> From: Po Lu <luangruo@yahoo.com>
>>> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
>>> Date: Mon, 04 Nov 2024 22:09:33 +0800
>>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>>> My point is that users frequently customize or exchange the positions of
>>>>> these modifier keys, and it is the resultant modifiers that they expect
>>>>> Emacs to report, not the keysyms, in special events or elsewhere.
>>>>
>>>> They should not expect that with these physical events, IMO.
>>>
>>> Why not?  If Caps Lock and Ctrl are exchanged, why should Emacs depart
>>> from every other program by not reporting Ctrl when the key labeled Caps
>>> Lock is depressed?
>>
>> On _physical_ level, there can be no "exchange of keys".  That
>> exchange exists on the logical level, where Ctrl followed by A yield a
>> single event whose value is 1, instead of 4 events (2 keypresses and 2
>> releases), none of which is 1.
> 
> No, that is configuring Caps Lock to serve as a Ctrl latch.  I'm
> speaking of remapping such a key to serve as _the_ Ctrl modifier, such
> that Caps_Lock+A yields an XK_Caps_Lock event that is discarded by Emacs
> as a modifier key, followed by a second event whose value is, yes, ^A,
> and with the Ctrl modifier bit set in its state.
> 
>>> Or, if another key than Hyper itself (which is not
>>> to be found on PC keyboards) is configured to serve as the Hyper
>>> modifier, surely we want it to be reported as Hyper?
>>
>> Again, not on this level.
>>
>>> The only reasonable manner of reporting these key events is reporting
>>> the modifiers that Emacs will generate in response to them.  The other
>>> correct approach, that of reporting X modifier bits uninterpreted,
>>> yields physical keys that are just as meaningless (ctrl, shift, mod1,
>>> mod2, mod3, and so forth) and with equally tenuous a relationship with
>>> the modifiers that users expect to receive from Emacs.
>>
>> They are presumably not meaningless to a Lisp program which wants to
>> receive such events.  Or at least this is my understanding.
> 
> I am interested to hear what use Lisp programs intend to make of a mod2,
> mod3, mod4, and mod5, whose meanings vary wildly from one machine to the
> next.  On my system, for example:
> 
> shift       Shift_L (0x32),  Shift_R (0x3e)
> lock        Caps_Lock (0x42)
> control     Control_L (0x25)
> mod1        Alt_L (0x40),  Alt_L (0xcc),  Meta_L (0xcd)
> mod2        Num_Lock (0x4d)
> mod3        ISO_Level5_Shift (0xcb)
> mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
> mod5        ISO_Level3_Shift (0x5c)
> 
> while on another:
> 
> shift		44 57	# Left Shift, Right Shift
> lock		30	# CapsLock
> control		58 64	# Control
> mod1		59 63	# Meta
> mod2		62	# AltGraph
> mod3		90	# NumLock
> mod4		60	# Left Alt
> mod5		65	# Compose
> 
> Without consulting the X11 modifier keymap (which is impossible from
> Lisp), how should a Lisp program derive any meaning from these modifier
> bits, or the keys to which they are assigned?

The idea is to report Shift_L, Shift_R, Alt_L, Meta_L not shift or alt. 
Maybe those keys are mapped to modifiers, maybe not.