Re: Physical keyboard events

[Po Lu <luangruo@yahoo.com>]

Cecilio Pardo <cpardo@imayhem.com> writes:

> On 04/11/2024 1:21, Po Lu wrote:
>
>> Thank you.  A number of comments: this is simply unacceptable, as Emacs
>> must not depend on XKB for such a basic feature.
>
> Ok.
>
>> ??? Code producing such events should not relay modifier keysyms
>> verbatim, but ought to detect the virtual modifiers to which they are
>> mapped, and convert them into Emacs modifiers, namely, meta, alt, ctrl,
>> hyper, super, and shift.  Otherwise, Lisp will find it impossible
>> reliably to establish a correspondence between "physical key events" and
>> modifiers.
>
> This is about keys, not modifiers. For the use case of binding
> commands to keys, this remapping would be counterproductive. I can
> provide a function to make that conversion if needed.

I must disagree.  When Emacs has enough information to decide which
modifiers are produced by physical keys it receives, as it does here, it
should not confuse Lisp programmers with a view of the keyboard state
that runs contrary to their expectations, not to mention that the
disparity between X keysyms and X modifiers is very great, and users who
swap the positions of the Shift and Ctrl modifiers will not expect to
receive raw keyboard events which disregard their keyboard
configuration.

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.

>> Please find some means of generating such events by saving them into the
>> keyboard event buffer defined in handle_ome_xevent.
>
> Ok.
>
>> x_filter_events is not the proper location for this call.  It is only
>> invoked to filter an event through the active GTK or X input method
>> context, and it is not invoked if Emacs is configured not to open input
>> method contexts, or they are unavailable by happenstance.
>> This call is properly placed in handle_one_xevent, beneath the
>> labels
>> for KeyPress, KeyRelease, XI_KeyPress, XI_KeyRelease, and the GTK
>> keyboard callbacks in gtkutil.c.  Pay attention to the different manners
>> in which the key codes are converted into keysyms and the keysyms into
>> modifiers, and imitate them closely or reuse them if possible.
>> Lastly, you must decide whether to capture modifier key events
>> before
>> they are filtered by the input method, or after.  Input methods have
>> complete discretion over disposing of these events and will either
>> discard them entirely or resend a possibly modified event to Emacs.  In
>> the latter scenario, you will receive duplicates of one and the same
>> event, and in principle it is impossible to distinguish between the
>> duplicates and the originals.  Equally unsatisfactory is the option of
>> generating these events after they are filtered by the input method,
>> since none will be generated if the IM takes the other course.
>> These are the same concerns that led me not to implement raw
>> modifier
>> key events when this feature was proposed some years ago.
>
> Then probably this should only support X11+gtk and pgtk. Do those look
> ok? Is it acceptable to have support for nonfree systems in this case?

It's not acceptable only to support X11+GTK and PGTK, whether or not
non-free systems are also supported, because there are numerous severe
deficiencies with those configurations, and with them we are at the
mercy of an upstream that is uncooperative at best.  And above all, what
I said applies just as well to the GTK configurations.