Allow kitty to 'automatically' input Unicode characters mapped in kanata and KMonad.

[j-steinbach]

Is your feature request related to a problem? Please describe.

I write in multiple languages (EN, DE, TR, FR, ..) which use different characters not commonly found on a US keyboard, such as ü. For this I use a software keyboard layout (KMonad, kanata to comfortably switch to the required set of characters.

Unicode input in Linux can be done via the Shift+Ctrl+U input method (for example <Shift+Ctrl+U> fc <return> produces ü, as per the Unicode table.

When done manually, this works in all relevant applications (Firefox, Thunderbird, Neovide, VSCode, ..), as well as the different terminals, such as WezTerm and Kitty.

But when using e.g. kanata, which allows me to create a custom layout that maps for instance [ to ü, then this produces the required input everywhere, except in kitty.

In kitty the manual method works, but the 'automatic' method stops at the Unicode picker.

I need to

1. Press [ a first time to open the Unicode picker
2. Press [ a second time to select the character
3. Press to leave the Unicode picker

Describe the solution you'd like

I want to be able to input characters without needing three button presses, similar as to every other application on my computer.

➜ I am not sure if this is a bug or a feature request, of I am just missing some option in my config, but I don't know what to search for

Describe alternatives you've considered

• Using WezTerm
• Finding a different way to input the characters (xkbcomp, ..)
• Looking through the kitty Unicode input documentation

[kovidgoyal]

I have no idea what kmonad is or how it works. If you want to use
unicode input on your Linux desktop, the correct way to do it is to use
the XCompose mechanism, that will actually work everywhere.
https://wiki.debian.org/XCompose

And if you want a kitty specific solution, use send_text
https://sw.kovidgoyal.net/kitty/conf/#shortcut-kitty.Send-arbitrary-text-on-key-presses

[j-steinbach]

Thank you very much for your reply! I think XCompose is then the way I will go forward, via KMonad, as described here.

I'll dump some last thoughts on my kitty specific issue, in case someone else comes across this. I hope that is ok for you, and feel free to ignore this.

---

We can (badly) generalize KMonad (and derivatives) as software that aggregates and sends key presses.

This works for most Linux applications, except for kitty.

More specifically, the Linux Unicode input[^1]. In kitty these aggregated key presses seem to get 'buffered'.

An automatic press of Ctrl-Sft-U fd <ret> only shows the behaviour of Ctrl-Sft-U, opening the kitty Unicode input dialog. A second press then sometimes adds fd or recurses as new Ctrl-Sft-U. Finally a third press closes the kitty Unicode input dialogues, but produces a scrambled result (e.g. df instead of fc).

To me it seems that kitty is not able to understand the full sequence at once. I am curious if a delayed sequence of Ctrl-Sft-U <delay> fd<ret> would make it work as 'intended'.

[1]: There seem to be a few different ways to do it; XCompose, the Linux Unicode sequence (apparently ISO-14755?), ...

[KenMacD]

I've also run in to this issue, and again it's only kitty that has an issue with the unicode sequences. To add some more data here, the following is the list of key actions being simulated through the virtual input device:

d:ControlLeft t:1
d:ShiftLeft t:0
d:KeyU t:2
u:KeyU t:0
u:ShiftLeft t:0
u:ControlLeft t:0
d:Digit2 t:1
u:Digit2 t:0
d:Digit0 t:1
u:Digit0 t:0
d:Digit1 t:0
u:Digit1 t:0
d:Digit3 t:1
u:Digit3 t:0
d:Enter t:0

The time after each key is in milliseconds, and so this whole sequence happens in under 10ms. This seems to be understood fine by other programs, but kitty seems to drop the keypresses that happen while it's bringing up the selector.

[kovidgoyal]

Timing is irrelevant. Your hack is sending N independent key events these are supposed to be interpreted as independent key events, not a single sequence. If you want to compose independent key events into a single sequence that results in some text, the only correct way to do it is via XCompose rules. Only an XCompose rule can tell an application robustly that the first key is the start of a sequence.

Anything else is a hack, that it works in some places is irrelevant, that is the nature of hacks they work until they break. Especially relying on timing to deduce key sequences is the worst of all hacks.

[KenMacD]

Thanks for the reply @kovidgoyal, but I'm really not understanding what you mean around the timing being irrelevant. From what I see of utility it's acting as a keyboard and sending the keypresses in the same way my keyboard does. It shows up under swaymsg -t get_inputs, for example.

If I could type the same speed it'd fail in the same way, and it's trying the same thing I'd type to make the symbol I want.

I tried adjusting delay values in:

ctrl+shift+u <delay> 2 0 1 3 ret

With a delay of around 90ms it starts to work sometimes. At about 95ms it works every time, below around 87 it fails every time (and the 2013 appears in the terminal before the empty Enter the hex code for the character prompt appears).

In other programs such as Firefox or lxterminal it works every time without any delay set at all.

[kovidgoyal]

Multi key inputs happen using special keys called dead keys. You need to
configure a dead key to start a multi key input. Simply sending multiple
keys fast is not going to work. Configuration of dead keys is done most
robustly using XCompose or failing that use an IME service for it. In
the former libxkbcomomn reads the XCompose files and tells the
application the a multi key sequence is in progress. In the latter the
IME service sends special events to the application indicating keys need
to be handled differently. Timing is utterly irreelvant.

[KenMacD]

Okay, that's interesting. I've never set up XCompose. For this particular issue I'll likely just set a delay though rather than deal with another solution that might just move the broken input from Kitty to Chrome.

Leaving aside the 'best way' to input key sequences and macros, I'd argue this is still a bug here. The same issue could be hit by anyone typing at 140wpm. The key sequence typed is still an expected manually input sequence, and so should work, even if typed quickly.

[kovidgoyal]

Except there is no timing code anywhere in the keyboard handlers in kitty, easy to check for yourself since its open source. As I said timing is the worst possible hack keyboard input can use hence kitty doesnt use it.

[KenMacD]

I wasn't suggesting there's any timing code in kitty. I think the bug is somewhere in how the unicode-input kitten is launched. For a brief period of time while the kitten is initializing the keyboard input appears to still be being read by kitty instead of the kitten.

If the kitten in run in the foreground with kitten unicode-input then any input I type while the kitten is loading does end up appearing in the prompt. If the kitten is run through the shortcut-key though the input ends up in the terminal and not in the kitten-readline-prompt.

[kovidgoyal]

Well, yes, that's not a bug. The kitten runs in a new window which is
created when the event loop ticks over, not instantly, this is by design,
for various reasons, creation of windows is asynchronous.

If all the keystrokes come in before the overlay window gets focus, they
will be delivered to the original window. In practice this is not an
actual issue, since the event loop ticks very fast. I am guessing your
keystrokes are all being delivered together, i.e. with zero delay in the
same event loop tick, which cannot happen when typing no matter how fast
one types. You can check that with --debug-input. Combine with
--debug-rendering to see where the new window is created and focused.

Although taking a step back I dont really understand what you are doing,
why do you need to invoke the unicode input kitten with predefined
keystrokes anyway? If you want to input a unicode character on specific
keystroke, you can do so using send_text in kitty.conf no need to go via
the unicode input kitten.

[KenMacD]

The kitten runs in a new window which is created when the event loop ticks over, not instantly, this is by design, for various reasons, creation of windows is asynchronous.

Thanks, I understand, and now have a better understanding of the 'why' of issue.

This may be from a lack of understanding of the design, but I don't suppose it would be possible to pause the processing of keys when a kitten is going to be executed, or perhaps allow specifying that some kittens should be launched synchronously? Or even allow a config that disables the kitten for a built-in not-as-fancy way.

which cannot happen when typing no matter how fast one types

For zero delay, for sure. I was still losing keystrokes up to about 85ms though, which is only 140wpm typing speed, so it doesn't seem impossible for this to also affect normal everyday users.

In case it helps I'll include a quick debug output of typing the digits 1 to 6 with 10ms between each (I trimmed out some mouse moves from the log):

Details

[0.104] Compositor missing capabilities: blur
[0.119] Creating window 1 at size: 1916x1142 and scale 1
[0.119] Loading new XKB keymaps
[0.130] Modifier indices alt: 0x3 super: 0x6 hyper: 0xffffffff meta: 0xffffffff numlock: 0x4 shift: 0x0 capslock: 0x1 control: 0x2
[0.130] Compositor top-level capabilities: maximize=1 minimize=0 window_menu=1 fullscreen=0
[0.130] XDG top-level configure event for window 1: size: 0x0 states: 
[0.130] XDG decoration configure event received for window 1: has_server_side_decorations: 1
[0.130] XDG surface configure event received and acknowledged for window 1
[0.130] Waiting for swap to commit Wayland surface for window: 1
[0.130] Final window 1 content size: 1916x1142 resized: 0
[0.130] Setting window 1 "visible area" geometry in configure event: x=0 y=0 1916x1142 viewport: 1916x1142
[0.130] Attached temp buffer during window 1 creation of size: 1916x1142 and rgba(13, 15, 49, 255)
[0.130] Waiting for compositor to send fractional scale for window 1
[0.131] Fractional scale requested: 120/120 = 1.00 for window 1
[0.131] Resizing framebuffer of window: 1 to: 1916x1142 window size: 1916x1142 at scale: 1.000
[0.131] Waiting for swap to commit Wayland surface for window: 1
[0.131] XDG top-level configure event for window 1: size: 956x1142 states: TOPLEVEL_STATE_ACTIVATED TOPLEVEL_STATE_TILED_LEFT TOPLEVEL_STATE_TILED_RIGHT TOPLEVEL_STATE_TILED_TOP TOPLEVEL_STATE_TILED_BOTTOM 
[0.131] XDG surface configure event received and acknowledged for window 1
[0.131] Resizing framebuffer of window: 1 to: 956x1142 window size: 956x1142 at scale: 1.000
[0.131] Waiting for swap to commit Wayland surface for window: 1
[0.131] Final window 1 content size: 956x1142 resized: 1
[0.131] Setting window 1 "visible area" geometry in configure event: x=0 y=0 956x1142 viewport: 956x1142
[0.131] Creating OpenGL context and attaching it to window
MESA: warning: Support for this platform is experimental with Xe KMD, bug reports may be ignored.
[0.175] Window 1 swapped committing surface
[0.223] OS Window created
[0.245] Child launched
[0.245] 
text-input: updating cursor position: left=5 top=7 width=11 height=23
[0.252] Changing cursor shape to: WP_CURSOR_SHAPE_DEVICE_V1_SHAPE_TEXT with serial: 0
[0.252] Got notification server capabilities: frozenset({'body-markup', 'actions', 'body', 'x-canonical-private-synchronous', 'icon-static', 'x-dunst-stack-tag'})
[1.895] Changing cursor shape to: WP_CURSOR_SHAPE_DEVICE_V1_SHAPE_TEXT with serial: 96657
[1.895] Mouse cursor entered window: 1 at 9.980469x734.605469
[1.902] Move x: 46.8 y: 731.4 grabbed: 0
[1.902] Changing cursor shape to: WP_CURSOR_SHAPE_DEVICE_V1_SHAPE_DEFAULT with serial: 96657
[5.529] Press xkb_keycode: 0x1d clean_sym: Control_L composed_sym: Control_L mods: none glfw_key: 57442 (LEFT_CONTROL) xkb_key: 65507 (Control_L)
[5.529] on_key_input: glfw key: 0xe062 native_code: 0xffe3 action: PRESS mods: ctrl text: '' state: 0 [5.529] 
text-input: updating cursor position: left=27 top=53 width=11 height=23
ignoring as keyboard mode does not support encoding this event
[5.530] Press xkb_keycode: 0x2a clean_sym: Shift_L composed_sym: Shift_L mods: ctrl glfw_key: 57441 (LEFT_SHIFT) xkb_key: 65505 (Shift_L)
[5.530] on_key_input: glfw key: 0xe061 native_code: 0xffe1 action: PRESS mods: ctrl+shift text: '' state: 0 ignoring as keyboard mode does not support encoding this event
[5.531] Press xkb_keycode: 0x16 clean_sym: u composed_sym: U mods: ctrl+shift glfw_key: 117 (u) xkb_key: 117 (u) shifted_key: 85 (U)
[5.531] on_key_input: glfw key: 0x75 native_code: 0x75 action: PRESS mods: ctrl+shift text: '' state: 0 
KeyPress matched action: kitten, [5.552] Child launched
[5.552] 
text-input: updating cursor position: left=5 top=7 width=11 height=23
handled as shortcut
[5.553] Release xkb_keycode: 0x16 clean_sym: u mods: ctrl+shift glfw_key: 117 (u) xkb_key: 117 (u) shifted_key: 85 (U)
[5.553] on_key_input: glfw key: 0x75 native_code: 0x75 action: RELEASE mods: ctrl+shift text: '' state: 0 [5.553] 
text-input: updating cursor position: left=27 top=53 width=11 height=23
ignoring release event for previous press that was handled as shortcut
[5.553] Release xkb_keycode: 0x2a clean_sym: Shift_L mods: ctrl+shift glfw_key: 57441 (LEFT_SHIFT) xkb_key: 65505 (Shift_L)
[5.553] on_key_input: glfw key: 0xe061 native_code: 0xffe1 action: RELEASE mods: ctrl text: '' state: 0 ignoring as keyboard mode does not support encoding this event
[5.553] Release xkb_keycode: 0x1d clean_sym: Control_L mods: ctrl glfw_key: 57442 (LEFT_CONTROL) xkb_key: 65507 (Control_L)
[5.553] on_key_input: glfw key: 0xe062 native_code: 0xffe3 action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event
[5.553] Press xkb_keycode: 0x2 clean_sym: 1 composed_sym: 1 text: 1 mods: none glfw_key: 49 (1) xkb_key: 49 (1)
[5.553] on_key_input: glfw key: 0x31 native_code: 0x31 action: PRESS mods: none text: '1' state: 0 sent key as text to child: 1
[5.553] Release xkb_keycode: 0x2 clean_sym: 1 mods: none glfw_key: 49 (1) xkb_key: 49 (1)
[5.553] on_key_input: glfw key: 0x31 native_code: 0x31 action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event
[5.557] Press xkb_keycode: 0x3 clean_sym: 2 composed_sym: 2 text: 2 mods: none glfw_key: 50 (2) xkb_key: 50 (2)
[5.557] on_key_input: glfw key: 0x32 native_code: 0x32 action: PRESS mods: none text: '2' state: 0 [5.557] 
text-input: updating cursor position: left=38 top=53 width=11 height=23
sent key as text to child: 2
[5.558] Release xkb_keycode: 0x3 clean_sym: 2 mods: none glfw_key: 50 (2) xkb_key: 50 (2)
[5.558] on_key_input: glfw key: 0x32 native_code: 0x32 action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event
[5.569] Press xkb_keycode: 0x4 clean_sym: 3 composed_sym: 3 text: 3 mods: none glfw_key: 51 (3) xkb_key: 51 (3)
[5.569] on_key_input: glfw key: 0x33 native_code: 0x33 action: PRESS mods: none text: '3' state: 0 [5.569] 
text-input: updating cursor position: left=49 top=53 width=11 height=23
sent key as text to child: 3
[5.570] Release xkb_keycode: 0x4 clean_sym: 3 mods: none glfw_key: 51 (3) xkb_key: 51 (3)
[5.570] on_key_input: glfw key: 0x33 native_code: 0x33 action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event
[5.573] Pushed key encoding flags to: 29
[5.574] 
text-input: updating IME focus state, ime_focused: 0 ev->focused: 1
[5.581] Press xkb_keycode: 0x5 clean_sym: 4 composed_sym: 4 text: 4 mods: none glfw_key: 52 (4) xkb_key: 52 (4)
[5.581] on_key_input: glfw key: 0x34 native_code: 0x34 action: PRESS mods: none text: '4' state: 0 sent encoded key to child: ^[ [ 5 2 ; ; 5 2 u 
[5.582] Release xkb_keycode: 0x5 clean_sym: 4 mods: none glfw_key: 52 (4) xkb_key: 52 (4)
[5.582] on_key_input: glfw key: 0x34 native_code: 0x34 action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event
[5.593] Press xkb_keycode: 0x6 clean_sym: 5 composed_sym: 5 text: 5 mods: none glfw_key: 53 (5) xkb_key: 53 (5)
[5.593] on_key_input: glfw key: 0x35 native_code: 0x35 action: PRESS mods: none text: '5' state: 0 [5.593] 
text-input: updating cursor position: left=60 top=53 width=11 height=23
sent encoded key to child: ^[ [ 5 3 ; ; 5 3 u 
[5.594] Release xkb_keycode: 0x6 clean_sym: 5 mods: none glfw_key: 53 (5) xkb_key: 53 (5)
[5.594] on_key_input: glfw key: 0x35 native_code: 0x35 action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event
[5.605] Press xkb_keycode: 0x7 clean_sym: 6 composed_sym: 6 text: 6 mods: none glfw_key: 54 (6) xkb_key: 54 (6)
[5.605] on_key_input: glfw key: 0x36 native_code: 0x36 action: PRESS mods: none text: '6' state: 0 sent encoded key to child: ^[ [ 5 4 ; ; 5 4 u 
[5.606] Release xkb_keycode: 0x7 clean_sym: 6 mods: none glfw_key: 54 (6) xkb_key: 54 (6)
[5.606] on_key_input: glfw key: 0x36 native_code: 0x36 action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event
[9.902] Mouse cursor left window: 1on_focus_change: window id: 0x1 focused: 0
[9.909] 
text-input: updating IME focus state, ime_focused: 0 ev->focused: 0
[9.909] XDG top-level configure event for window 1: size: 956x1142 states: TOPLEVEL_STATE_TILED_LEFT TOPLEVEL_STATE_TILED_RIGHT TOPLEVEL_STATE_TILED_TOP TOPLEVEL_STATE_TILED_BOTTOM 
[9.909] XDG surface configure event received and acknowledged for window 1
[9.909] on_focus_change: window id: 0x1 focused: 0
[9.909] 
text-input: updating IME focus state, ime_focused: 0 ev->focused: 0
[9.909] Final window 1 content size: 956x1142 resized: 0
[9.909] Setting window 1 "visible area" geometry in configure event: x=0 y=0 956x1142 viewport: 956x1142

I dont really understand what you are doing, why do you need to invoke the unicode input kitten with predefined keystrokes anyway?

Basically I like to use text expanders to save on typing. I was using Espanso so that instead of typing my email every time I can just type :em; or :myip to insert the ip address I get from dig +short myip.opendns.com @resolver1.opendns.com. I've been trying to migrate that config over to kanata so I can add configuration like having the caps-lock be escape when tapped but ctrl when held. As part of these configs I want some macros to insert common unicode characters I use without having to remember the code for them, for example for emdash.

While I'm doing this with software macros at the moment I've also considered picking up macro-keyboard which has a few programmable buttons that then send multiple keypresses.

I've heard and appreciate what you've said on having the window manager handle unicode input, and I plan to have a look. That does add extra complication though over a macro-key simple entering the same thing I would type to get the unicode character.

I also hear what you're saying about send_text, but while that might work for kitty I would still need another option for all the other programs I use.

As it currently stands all the other programs I use day to day handle the super-fast entering of unicode characters (Signal, Firefox, VSCodium, Podman Desktop, etc). It's only on kitty that I've run in to an issue.

I understand if you don't have the time/resources/desire to do anything about this. I've worked around the issue by just adding a 100ms delay to give the kitten enough time to start. I've simply included this info so that if others run in to the same issue I did and end up here a well, that the limitation and workaround is documented.

[kovidgoyal]

On Wed, Dec 11, 2024 at 09:55:45AM -0800, Kenny MacDermid wrote: > The kitten runs in a new window which is created when the event loop ticks over, not instantly, this is by design, for various reasons, creation of windows is asynchronous. Thanks, I understand, and now have a better understanding of the 'why' of issue. This may be from a lack of understanding of the design, but I don't suppose it would be possible to pause the processing of keys when a kitten is going to be executed, or perhaps allow specifying that some kittens should be launched synchronously? Or even allow a config that disables the kitten for a built-in not-as-fancy way.

It's certainly possible to buffer key presses, but not worth the effort.

> which cannot happen when typing no matter how fast one types For zero delay, for sure. I was still losing keystrokes up to about 85ms though, which is only 140wpm typing speed, so it doesn't seem impossible for this to also affect normal everyday users.

Yeah that's because thank's to wayland's crazy design kitty has to wait for the compositor to map the window and assign it a size before actually launching the program running in it to avoid spurious WINCH signals. On more well designed display system the delay is much shorter. That said, I have not seen a single report of this from anyone just typing. While typing to launch a window one needs to typically press a multi key shortcut these dont allow typing at high speed.

I also hear what you're saying about `send_text`, but while that might work for kitty I would still need another option for all the other programs I use.

My point was even if you are setting up a macro globally why does it need to launch the unicode input kitten at all? That is already kitty specific since your macro is presumably pressing the key the kitten needs to function. Instead just have your macro send the text directly via IME or map it to a keypress that in turn sends the text via send_text in kitty.conf. Launching a whole new program in a new window just to get a unicode character seems very excessive to me.

[kovidgoyal]

Actually, I decided to implement the bufferring as it was not too much work.