Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve keyboard layout handling #2000

Closed
bew opened this issue Sep 24, 2019 · 15 comments
Closed

Improve keyboard layout handling #2000

bew opened this issue Sep 24, 2019 · 15 comments

Comments

@bew
Copy link
Contributor

bew commented Sep 24, 2019

This issue will track progress and discussion to improve keyboard layout handling. (continuing the discussion started in #1980)

TL;DR: #1990 & #1980 should work out of the box.

What

Make 'composed' shortcut work with any modifiers (need to rephrase?)
With the french keyboard layout, typing shift+: should send / to the terminal app, and alt+shift+: should send ^[/.
The former already works, but the latter does not send anything (this is the problem description of #1980).
Same problem with #1980 (comment) (alt+altgr+" should give alt+#).

Handle non-standard modifiers from keyboard layouts
Given some_mod+X with some_mod a non standard mod like ISO_Level2_Shift.
Currently when X is a key that exist directly in the US layout, the resulting key is the shifted version of the matching US layout key (was done because of #171 (comment)).
This would also fix #1990.
→ Correct layout handling should fix this automatically

Allow kitty shortcut using resolved keys and real pressed keys
To make map alt+shift+: ... work the same as map alt+/ ...
→ This will be easy once we make GLFW report both on a key event!

Idea - keyboard layout agnostic Kitty shortcut
It would be nice to have layout-independent kitty-shortcut, using a special syntax like map @ctrl+shift+c ... (we're back to #606..), so that you can switch between (e.g) French and Russian and still be able to use these Kitty shortcuts.
(or map! ctrl+shift+c ... to avoid any key clash and give a kind of semantic "it should always work!!")

Existing behaviors to keep

  • when the key is not recognized by GLFW (e.g: when using a Russian layout), fallback to the key on a US layout

How

  1. Extract glfw key event to a struct, to make futur changes easier (Extract glfw key event data to a struct #1998)
  2. Experiment with xkbcommon 🛠️
    The idea is to check with xkbcommon the modifiers consumed by the resulting key (ex: shift for shift+:)

I'll update this post when I find other things!

@Luflosi
Copy link
Contributor

Luflosi commented Sep 24, 2019

Actually the Russian keyboard layout should work, I'm pretty sure I added all the keys for it.
Other than that, this looks promising.

@bew
Copy link
Contributor Author

bew commented Sep 25, 2019

Actually the Russian keyboard layout should work

Oh right, then for other people with weird symbols 😃

Either way, it would be nice to be able to make kitty-shortcut that are layout independent, using a special syntax like map @ctrl+shift+c ... (we're back to #606..), so that you can switch between french and russian and still be able to use these Kitty shortcuts!
I'll add it above

(or map! ctrl+shift+c ... to avoid any key clash and give a kind of semantic "it should always work!!")

@Panke
Copy link

Panke commented Mar 9, 2020

Is there any progress on this? I have the same issues with the neo layout.

@maksbotan
Copy link

Re Russian layout. Some time ago after Kitty update I've noticed a problem: no shortcuts work when Russian layour is selected. For example, I've used to be able to press Ctrl-C or Ctrl-w on any layout, but now it works only on US layout. This is very annoying.

Can it be reverted until you find a proper solution? Because it worked before.

BTW, strangely, I started to experience the same problem on macOS recently.

@bew
Copy link
Contributor Author

bew commented May 3, 2020

Is there any progress on this? I have the same issues with the neo layout.

Hi, sorry didn't see your message. I don't have much time for personal projects currently, so no, no progress on this. Also as I'm (unfortunately) forced to use windows at work (and have some of the same problems, but it's another topic ^^) I don't really use kitty at the moment.

@maksbotan
Copy link

@kovidgoyal hi, can you also please respond to my problem above (#2000 (comment))?

@kovidgoyal
Copy link
Owner

Use debug keyboard to see what keys w and c are in your layout and map them using send_textto send the bytes corresponding to ctrl_w and ctrl+c

@maksbotan
Copy link

Well, this is rather clumsy, given that it used to work. Could you revert the change that broke it?

@kovidgoyal
Copy link
Owner

This has already been discussed elsewhere, read up on it, or if you dont have the time, just implement the workaround.

@Luflosi
Copy link
Contributor

Luflosi commented May 6, 2020

Here is the issue where this has been discussed: #606. I think some of the comments towards the bottom might be what you're looking for but I would recommend reading the entire issue.

@maksbotan
Copy link

@Luflosi thanks! Somehow I missed #606 while reading this thread. Sorry!

I'll hope that this issue will be eventually resolved.

@maksbotan
Copy link

So for anyone finding this issue in the future, here are bindings for most basic keys (^C, ^D, ^H, ^W):

map ctrl+CYRILLIC_ES send_text all \x03
map ctrl+CYRILLIC_VE send_text all \x04
map ctrl+CYRILLIC_ER send_text all \x08
map ctrl+CYRILLIC_TSE send_text all \x17

This will make them "work" on Russian layout the same way as they do on English.

@nikto-b
Copy link

nikto-b commented Jun 28, 2020

Not sure that is that, but I have some troubles with handling keyboard using Russian language in sway
Have no idea about the cause, but it exists
zsh 5.8 (x86_64-pc-linux-gnu)
One
Two
Three

kovidgoyal added a commit that referenced this issue Jan 17, 2021
…y matches an English key in the default layout, send that to the program running in the terminal automatically

See #2000
@kovidgoyal
Copy link
Owner

This should be fixed in master, though I have not tested it much given I only have standard pc keyboards.

@Jakeroid
Copy link

Here is mine solution. Actually, the idea is the same to map each shortcut for the non-Latin character, but I made automated script to do that.

https://jakeroid.com/blog/kitty-shortcuts-work-only-with-latin-characters-how-to-fix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants