keyboard layout agnostic shortcuts #606
Comments
|
And doing that would make it impossible to use compose keys to enter non-english text. Which would make lots of other people unhappy, see #171 |
|
I read the thread, but didn't fully understand why it would prevent using compose keys, could you explain a bit more? I have something like that working on my laptop, I press AltGr+o, / to make a Danish letter ø, is that what compose key is and why this would break? |
|
Because compose keys in general work by using some modifier to change the action of normal keys or by re-assigning normal keys to mean something else. There is no way for a key event consuming application to know which is which. Either an application uses the compose and layout rules to figure out which key the user meant to press, or it does not. It cannot do so selectively on an ad hoc basis. Your russian keyboard layout is mapping the c key to some cyrillic character. if you dont like that, the proper solution is to modify the russian layout, not add workarounds or it to every application you use. |
|
The layout maps all keys to cyrillic characters as Russian uses cyrillic alphabet instead of Latin one, that's the whole point of having the second layout in the first place 😀 Problem is, currently kitty terminal cannot be controlled if you only have Russian layout, you have to install English layout just to get the Latin letter "C" so that kitty can start recognizing Ctrl+C and Ctrl+Shift+C. Other terminals manage to understand these key presses regardless of active layout (and by the way, I am able to type AltGr+o, / to get Danish ø in sakura terminal). Regardless, this pain extends beyond kitty, I didn't have high hopes for this issue to be solved. Thanks for explanations though 😉 |
|
In that case what you need to do is add rules to the layout to map Ctrl+C to Ctrl+C and not That should fix it in all applications that respect keyboard layouts. |
|
Interesting, I will have a look, thanks for the idea! |
|
This was a very neat idea, but unfortunately I couldn't find how to do this. There is a keymap table where you can define what a given key should do depending on the currently hold modifier keys, but Ctrl is not in that list. All I saw about Ctrl is people reassigning it to a different key, but that doesn't help us here. If someone finds a solution, please share. |
|
Did you look at XCompose? |
|
Not yet, just started looking 👍 But look what I found in meantime with English layout, press "d", xev sees it as "d" (expected): Russian layout, press "d", xev sees it as cyrillic "в" (expected): English layout, press "Ctrl+d", xev sees it as "Ctrl+d" (expected): Russian layout, press "Ctrl+d", xev sees it as latin "Ctrl+d": I'm tempted to say kitty should do the same since xev does this out of the box, what do you think? |
|
Take it up with the maintainers of libxkbcommon. It isn't kitty that decides what keys to report, it is libxkbcommon. See the glfw_xkb_handle_key_event function. IIRC xev doesn't use libxkbcommon it uses xlib. Most modern software uses libxkbcommon since it works with both X and wayland. |
|
Another application-level idea: can we make kitty accept bindings for cyrillic letters? For example: Or if it has to be a keysym reported by At the minimum, I'd like to be able to add 4 bindings so that these work when Russian is the active layout: |
|
It has to be keys known to glfw, since the kitty layer sees only glfw key codes. And glfw does not have codes for keys beyond the basic ascii keys. But, thinking about it, one way to do this is that, if the key is unknown to glfw in the current layout, then use the key name from a fallback keyboard layout that can be configured via a config option in kitty. That should be robust against changes in kernel/graphics stack and that way the user can configure exactly what layout to use a fallback for keys that do not match. The only question is, how to get xkb to load such a layout. Currently it loads the layout from the X server or wayland compsitor. I think this API is what we need https://xkbcommon.org/doc/current/group__keymap.html#ga502717aa7148fd17d4970896f1e9e06f |
|
And, I dont think this even needs a kitty config option, since it is controlled via an environment variable already, see https://xkbcommon.org/doc/current/structxkb__rule__names.html |
|
Note that I have not tested the fix, I leave that to you. |
|
Wooohooo, it works, thank you so much!!! 🎉 No more annoyances when I copy something with Ctrl+Shift+C only to realize later that I didn't copy anything because my layout was Russian. Ctrl+C, Ctrl+D, Ctrl+Shift+C, Ctrl+Shift+V, all work now in Russian layout — and by the way I didn't have to configure absolutely anything, not even environment variables, I think it figures out the fallback on its own because I have both layouts configured. |
…map shortcuts using the ascii equivalents, from the default layout. Fixes kovidgoyal#606
|
This issue should probably be reopened now, since the fix implemented in 4711746 no longer works: Cyrillic characters were added to Maybe I don't understand the full picture here, but I cannot imagine a use case for a keybinding attached to a Cyrillic letter — a user would have to switch layouts to access that keybinding, making it rather impractical. On the other hand, the effect of the change in e619eb9 is that now I have to manually add mappings to (Strictly speaking, 4711746 does not provide fully layout-agnostic keybindings for Cyrillic layouts, since some punctuation characters, "known" to GLFW, are moved to different positions. But it is probably as good as a keysym-based solution can be.) |
|
I dont really see what can be done here. shortcuts needed to be mapped to letters after the keyboard layout is done. Otherwise you cannot use for example a dvorak layout, or any layout that remaps keys. If pressing ctrl+c on your keyboard generates keycodes for ctrl+(something else) after layout mapping, then you have to bind to that (something else) in kitty.conf. The only real solution would be to have an smap command that maps to values in the default/no layout case. In order to do that, the entire keyboard handling stack in glfw (both xkb and cocoa) and kitty would need to be re-written to pass two keycodes to kitty, the code after layout mapping and the code before layout mapping. And there was an effort underway to do that by @bew see #2000 I suggest you contribute to that effort if you want to move this forward. |
|
According to https://sw.kovidgoyal.net/kitty/conf.html#keyboard-shortcuts, one should be able to use raw system key codes but when I tested it, I couldn't get it to work. |
|
raw system codes only apply if the key is unknown to glfw which cyrillic |
|
Ok. I think that should be mentioned in the docs. |
|
@tertium It all started when I wanted to be able to bind any key on my German keyboard in kitty. On German keyboards, there are additional characters not found on the English layout like äöüß and basically all of the non-alphanumeric characters are in different places. Since many other non-English keyboard layouts were also not fully supported, I just added them too while I was at it. The addition of Cyrillic characters might be debatable in terms of its usefulness but I saw no reason not to add them. Feel free to remove them again in your fork if they bother you. I am even willing to provide you with a patch if you find it too difficult to do yourself. But the correct way to achieve what you want is not to remove the keys from GLFW but to do what is described in #2000. @ctrlcctrlv Yes, keyboard handling is very different in kitty's version of GLFW compared to the original GLFW because the original keyboard handling was insufficient for kitty, see for example glfw/glfw#1140. |
|
To make myself clear, I do see the point of adding the characters like However, I don't think it makes sense for alternate alphabets like Cyrillic, since these are usually delegated to a separate ISO group: pretty much every Russian-speaking user would have Edit: @Luflosi I posted my comment before seeing yours. Removing the cyrillic symbols from |
|
In #606 (comment), @maximbaz asked for keyboard bindings with Cryllic letters, so there seems to be at least some use case for supporting them. |
Well, he asked for this because the standard shortcuts ( (Not trying to start an argument, nor waste your time. My problem is solved, so now I just want to explain my reasoning. I do understand your position, too.) |
|
Personally, I have no opinion on the appropriateness of adding cyrillic In the meantime I suggest simply adding the mappings for the shortcuts |
|
Rather surprising to see an advanced terminal emulator (graphics protocol, hinting, remote control, etc) has issues with such a basic thing as keyboard layouts :) Ok, I can add additional shortcuts to kitty.conf with Russian letters for kitty-specific actions. Do I understand it right that there is currently no way to deal with shell keybindings (like Ctrl-C, Ctrl-D, Ctrl-Z) in kitty with Russian layout? (without digging into the code, to be sure). |
|
No, you understand wrong. See send_text. |
|
Works, thanks. |
|
so how can I use now kitty hotkeys in non-us layout without a long list of each in config? |
|
@kovidgoyal hey, AFAIS, this ticket is about hotkeys sent to the terminal itself. But what about the kitty hotkeys? Here I try to open the new tab. It works in EN layout, but failed in RU: ^d works for EOL, as you can see. |
For eg: RU layout, CTRL-S shouldn't result in ы in the context of a terminal. The approach taken here is similar to kitty; when the key combination doesn't produce a definitive composed output, and when any of ctrl/alt/super are present, we treat the keypress as though it were the same as the one from the system default keymap. The result is that ctrl-c now works like ctrl-c and alt-b and alt-f work like their latin counterparts. Hopefully there are no downsides to this! refs: #2845 refs: kovidgoyal/kitty#606
|
I have same issues with all Cyrillic layouts (Ukrainian, Bulgarian, etc). Looks like if you have active layout with non-Latin characters you can't use shortcuts. Probably the solution is adding additional mapping for each your non-Latin keyboard layout. |
|
I created the script to automate the process, check the last part of the article here: https://jakeroid.com/blog/kitty-shortcuts-work-only-with-latin-characters-how-to-fix |
I have two keyboard layouts, English and Russian. I noticed that when the active layout is Russian and I press Ctrl+C,
sakuraandxtermcancel the currently running command, but kitty does not. Same for Ctrl+D,sakuraandxtermexit terminal, but kitty does not.This is because kitty recognized the cyrillic letters being pressed and ignores such weird commands.
It would be much much more pleasant if kitty would be layout agnostic and bind itself to the scancodes instead of ascii letters. In fact, my
i3has all shortcuts configured by scancodes so that the desired action consistently happens regardless of the currently active keyboard layout.Ctrl+Shift+C is another common annoyance, when Russian layout is active, kitty doesn't copy the selection.
I'm thinking now, ideally kitty would ignore active layout and think that I have english layout when Ctrl is pressed, so that for example even Ctrl+/ is treated exactly as
Ctrl+/regardless of active layout (in Russian keyboard that physical key represents.). This doesn't happen today insakuraorxterm.The text was updated successfully, but these errors were encountered: