[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Physical keyboard events
From: |
Eli Zaretskii |
Subject: |
Re: Physical keyboard events |
Date: |
Tue, 29 Oct 2024 18:44:36 +0200 |
> Date: Tue, 29 Oct 2024 16:07:16 +0100
> Cc: emacs-devel@gnu.org
> From: Cecilio Pardo <cpardo@imayhem.com>
>
> On 29/10/2024 14:40, Eli Zaretskii wrote:
>
> >> I'm planning to implement physical key press/release events for emacs.
> >> I would add a new element to 'enum event_kind', that in turn would
> >> send a new input event. This input event will be bound in
> >> 'special-event-map' so that it will not modify the normal flow of
> >> keyboard input. Platform dependent code would send these events
> >> on key press and release.
> >
> > I hope these new events will not be sent at all times, only when some
> > optional variable is set (similar to track-mouse, perhaps). I
> > wouldn't want Emacs to start processing press/release events on Shift
> > or Ctrl unless a Lisp program needs that, and I don't think we want to
> > change our processing of keyboard such that instead of a single
> > keypress with modifiers we need to process multiple key-press and
> > key-release events when the user simply types on the keyboard.
>
> Thats why the events will be bound in special-event-map. Nobody will see
> them, except for the code that handles them. We can of course
> completely disable them with a variable.
Even if no one sees them, bombarding the Emacs event queue with
useless events will have its effect: Emacs will become more sluggish,
some while-no-input loops will unexpectedly exit just because the user
happened to touch the Shift key for some reason, etc.
> > Physical keys also raise the issue of supporting input methods,
> > keyboard layout switches, etc.
>
> I will define a list of keys: LeftShit, RightShift, LeftControl, etc.
> The platform dependent code will decide which one was pressed. As events
> will be invisible, I don't think we will interfere with input methods.
I meant the non-modifier keys. When some OS feature redefines a key,
low-level events will not know that, and will still consider the key
labeled 'a' as 'a', even though I might have switched the keyboard to
another language, where the key labeled 'a' actually produces a
completely different character, say, 'ש'.
> > However, on what systems and which Emacs configurations will it be
> > possible to provide such a feature?
>
> I think all GUI systems can use this.
So X (with or without any toolkit we support), PGTK, MS-Windows, and
macOS -- all those let applications access low-level key events?
- Physical keyboard events, Cecilio Pardo, 2024/10/28
- Re: Physical keyboard events, Eli Zaretskii, 2024/10/29
- Re: Physical keyboard events, Cecilio Pardo, 2024/10/29
- Re: Physical keyboard events,
Eli Zaretskii <=
- Re: Physical keyboard events, Yuri Khan, 2024/10/29
- Re: Physical keyboard events, Eli Zaretskii, 2024/10/29
- Re: Physical keyboard events, Max Nikulin, 2024/10/29
- Re: Physical keyboard events, Yuri Khan, 2024/10/30
- Re: Physical keyboard events, Peter Feigl, 2024/10/30
- Re: Physical keyboard events, Eli Zaretskii, 2024/10/30
- Re: Physical keyboard events, Yuri Khan, 2024/10/30
- Re: Physical keyboard events, Eli Zaretskii, 2024/10/30
- Re: Physical keyboard events, Dov Grobgeld, 2024/10/30
- Re: Physical keyboard events, Juri Linkov, 2024/10/30