This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
bug: normal mode hardcoded with english layout #133
Comments
whoizit
changed the title
This comment was marked as outdated.
This comment was marked as outdated.
|
so is this a text editor or a code editor? Constantly switching the layout to get work in default mode is a pain for everyone in the world who speaks more than just English. And who writes more than just code. |
This comment was marked as outdated.
This comment was marked as outdated.
Alternate mappings are the sensible solution to this problem(wouldn't call it a bug), the alternative is a very bloated base configuration. Especially given the way crossterm keycode mappings work https://docs.rs/crossterm/0.19.0/crossterm/event/enum.KeyCode.html |
|
As someone that uses an alternate layout too (Norman) I can sympathize with the problem. This needs some changes in crossterm: We'd need to be able to receive raw position-based key codes but crossterm only offers us key chars. |
|
I also use an alternative layout (dvorak) and use IME to type chinese and japanese. I don't see an issue here besides the invalid IME position. But yeah, maybe non-latin (but non-pictographs) are an issue. What do you suggest? |
|
I've recently been dealing with this issue on other projects. The good news (once a gui lands) is that winit will very soon have the tools to fix this problem for real (this wasn't the case a few months ago). I'm interested in helping out in this area as its fresh in my mind at least on the gui side |
I speak cantonese and mandarin and malay as well but I don't have any issue with the defaults. At least I still use a US keyboard so this must have affected those that use non-us keyboard like in europe. I think there should be a flag. I still prefer to use key chars rather than keycode. The default keys for dvorak is still good for me to use it. A temporary solution right now is to use the key mappings configuration. @whoizit you can map out the keys and submit it to contrib/ or something so that others is able to use it. Or maybe have something like the current theme configuration where you can just |
|
|
|
If there is a possibility to access scancodes directly past the terminal, it would be possible to avoid having to implement CSIu mappers like this one (you see the extend of the problem) in order get access to some key combinations. It would be a solution at the root. Maybe helpful: A.f.a.i.r. and as the
It looks like a definite route to obviate CSIu hacks for the century-old ASCII limitations on key combinations. |
|
I am not (yet) a helix user, I have not read the thread (hard work for me, not english speaker). Bindings to keysyms are layout-dependent. This can be changed with the --to-code flag. In this case, the keysyms will be translated into the corresponding keycodes in the first configured layout. so i can do even so: all I changed from the default (us-only configuration) is do not confuse bindsym and bindcode |
|
For a text editor to become an extension of your brain through your fingers in 21st century, we need to stop this awful indirection going through the visual cortex (a.k.a. key char aliases) just to make modal keystroke decisions. I guess a blind person would be a real good "post modern" advisor, but just start by imagining a world where there are no markers on keycaps at all, all blank. 😜 In my opinion, the implementation primitives should embrace some representation of "muscle memory" intent-locators instead of chars and make char a higher order abstraction of that. Universal AFAIK key codes are constrained by those awful ASCII terminal constraints |
|
by the way, someone may not use the |
Very true, I really just wanted to complement the discussion with a radically different angle in the hopes that this angle can make In terms of locators, each finger has it's own coordinate system from the resting position. So the matrix is not a parallel one but a curved one, according to the form of the hand. Rectangular keyboards are just a very shameful violation of (human) hand ergonomics and should not be the inspiration for our primitives (they are a special "synchronized" case of the "ergonomic" coordinate system). Less chars, which do not have any vector information at all w.r.t. the resting position of any particular finger. Note that flexing vectors are "ergonomically" cheaper, than stretching vectors. At least for my hand and an ergonomic keyboard, that makes the row below the home row real second-to-prime estate. Ergonomically, this completely invalidates using char aliases as primitives for modal commands. — albeit, they surely are great helpers for the initial setup (+ maybe an ease in period until muscle memory is sufficiently trained). I hope I don't sound too radical, though. 😺 |
That somewhat works, but it requires elbow movements for smaller hands. But don't get me wrong, I just want to strengthen the point why char references are bad, so that we can have layout-independent-modal commands as a collateral outcome of a new paradigm. 😅 |
kirawi
added
A-keymap
|
Hi, I'm just being curious: How do You handle the case with other programs? So You set up Your editor to keycodes, but every other application still uses other keys. Do You reconfigure them too? For example vim bindings are quite common, it seems quite a lot work to setup everything. I use hungarian keyboard, searching( I have found https://github.com/samvel1024/kbct which seems a global solution for this problem. OTOH if I remap |
|
Hello, I'm also interested in looking out how to advance on this subject, I'm using bépo (a french dvorak-like variant), and it'd be really nice if it were possible to have the possibility to use scancodes or some sort of keycode translation to describe default bindings. It would greatly reduce the amount of rebinding I have to do with editors. For the time being, I only found the implementation in SDL, which apparently is only able to go back from keycode to scancode by manually testing all scancode candidates. Because of this I think that hoping to access scancodes directly is a tough sell, and to avoid perf related issues, I guess the "way to go" would be to:
With this, there'd be no remapping for anyone, and non-qwerty users would have a way to get at least home-row normal mode bindings out of the box. A lot of mnemonic keys would get moved to weird places though (in my examble, yanking becomes It probably has already been proposed but I'm not sure I saw it, if I'm saying obviously bad stuff please correct me, Regards, |
pickfire
added
the
E-help-wanted
|
I don't know if it's possible, but maybe we could provide that above function within Helix? |
|
A simpler alternative is rewrite the keymap for specific keybinding. Even as a dvorak user myself I don't find this useful. Probably need to wait for someone that is interested enough in this to fix it or just create a keymap which is less effort and works well. |
|
I do a continue to do custom build for this. thanks to |
you are looking at the wrong docs https://toml.io/en/v1.0.0#keys
|
|
Just another voice for a properly implemented langmap-like feature.
" swap j/k/l keys with d/r/n to get movement keys on German Dvorak
set langmap=dj,rk,nl,DJ,RK,NL,jd,kr,ln,JD,KR,LN
" don't override mappings for plugin generated input
set langnoremap |
Adds a config option to remap keys in a different keyboard layout into
English so that keybindings work even when switched into a non-English
keyboard layout.
The corresponding config option is `editor.layout-remap` which is a
list of dictionaries with two mandatory keys, `from` and `into`, which
specify the translation mapping, e.g.:
```toml
[[editor.layout-remap]]
from = 'йцукенгшщзхъЙЦУКЕНГШЩЗХЪ'
into = 'qwertyuiop[]QWERTYUIOP{}'
```
These can be repeated multiple times to facilitate specifying mappings
containing different types of quotes and other special characters
which may require escaping in TOML config.
This circumvents helix-editor#133 in a way that Helix still does not recognise
keypresses by their scan-codes but still allows for the non-English
layout users to operate Helix without switching the layout which can
be especially useful for writing documentation in their native language
with Helix.
Adds a config option to remap keys in a different keyboard layout into
English so that keybindings work even when switched into a non-English
keyboard layout.
The corresponding config option is `editor.layout-remap` which is a
list of dictionaries with two mandatory keys, `from` and `into`, which
specify the translation mapping, e.g.:
```toml
[[editor.layout-remap]]
from = 'йцукенгшщзхъЙЦУКЕНГШЩЗХЪ'
into = 'qwertyuiop[]QWERTYUIOP{}'
```
These can be repeated multiple times to facilitate specifying mappings
containing different types of quotes and other special characters
which may require escaping in TOML config.
This circumvents helix-editor#133 in a way that Helix still does not recognise
keypresses by their scan-codes but still allows for the non-English
layout users to operate Helix without switching the layout which can
be especially useful for writing documentation in their native language
with Helix.
|
+1 VSCode gets this right. Currently, helix needs an additional two keystrokes for every input to switch to / from foreign language. |
|
I have read this discussion carefully, and I would like to add my personal testimony. Like @gagbo I'm using the bépo layout (some kind of french dvorak), and I want to give it a try to helix. After thinking about it, I came to the conclusion that the easiest way for me was to use the qwerty us layout in normal mode, and the bépo layout in insert mode¹. Since there's no equivalent of Vim's langmap, I wanted to remap all the commands (from documentation keymap page) to simulate a qwerty us keyboard under the [keys.normal] section of config.toml. Unfortunately I soon found that this wasn't possible to do it in a consistent way, starting with the basic command "repeat last insert", which cannot be remapped. But there's worse: at the place of the y on the qwerty us there is a dead key (which doesn't generate a character by itself) on the bépo. (Moreover, in the case of the dot to repeat the last insertion, it is also very annoying in azerty, the most widespread keyboard in France, because the dot is not directly accessible, you have to press shift in same time.) ¹ For the more curious, I let you see where the h, j, k and l keys are on a bépo keyboard: https://bepo.fr/ (the layout is displayed at the top of the home page). And that's far from the only difficulty, you can also search for [ and ] as a second example. |
|
to be honest i would prefer for the command mode to use the scancode or keyid instead of remappings. swiss german or swiss french keyboards have a dead key on the english ] position. something in the lines of this tiny library. |
Scancodes don't work well at all for anything that is not a level-zero (direct input) key as you don't have an easy way to infere what scancode + modifier (shift, alt, ctrl, super, meta, option) maps to because that's something the OS keyboard layout is responsible for. And this doesn't even account for modifier combinations or the famous ISO-Level3 shift (alt-gr) that German and so many of our European languages have and which are the only way to access things like {[]}@. EDIT in addition to this it also completely ignores the idea of being able to remap some keys but not all - going by scancodes entering Insert mode on a dvorak layout would - for example - require pressing 'c' (which is the physical 'i' key) and that makes mnemonics completely useless. |
the beautiful thing with helix, vi is that it does NOT use modified keys on the command mode. for entering text a different mode is used fortunately, i am happy how it behaves now. remapping scancodes should be as well possible, it is just a parameter?
vi / helix command mode reminds me on a terminal game - easy to type - and this is good so :) i d love to see the person first, who uses dvorak and insists on mnemonics. true, the i - insert mnemonics is gone on a dvorak, for others like the "hjkl" key navigation mnemonics was always the terminal game mnemonics. that one is masochistic to type on dvorak btw. @geieredgar , as you have experience with game engines as well and editors. what woudl you recommend? how do games handle different keyboard layouts, to have a simple and easy to remember setting, ideally with a default which needs no configuration for most? |
Well using keycodes for input mode but scancodes for everything else sounds like a great mess and rather complicated to implement requiring two models of requesting input from the OS for each platform helix runs on..
Well you found one.. and honestly, mnemonics are key for all modal editors like vi, vim, nvim, helix and kakoune unless you are one of the persons that constantly looks at the letters written on the keys while typing. Call me wrong but 'c' doesn't really associate mentally with 'Insert', does it? Or 'uh' for 'go home / start of line', neither would ',' make sense to move words or 'e' for "delete" or 'q' to select the current line - all of these rely on mnemonics and don't work with scancode-based command modes unless you remap every key at which point you don't need scancodes anymore. (P.S. all of these examples are the scancodes that correspond to 'i', 'gh', 'w', 'd' and 'x' respectively when typing on a dvorak-DE layout. All of these work as expected with something like langmap / langnoremap in vim and nvim without needing scancodes) |
|
There is a solution for the (n)vim/kak/VScodeVIM editors : plugins like |
Sadly also only a workaround at best - as a foreign keyboard layout user you'd probably still only want to remap certain keys to the "intended places" (think where hjkl is) but keep the others where your layout has them so you can blind type the mnemonics without having to switch your brain back and forth between two layouts. One workaround I've found that works for my DVORAK-DE layout - but it's wanting as it takes away some of the Alt+Key combinations - is to use Alt + H/D/R/N (the layout keys I get when pressing the physical h/j/k/l) and remap them to the cursor move and selection commands like this, but it's more of a hack than a real fix :| # workaround for ALT + phys h/j/k/l movement on DVORAK-DE (just a sample)
[keys.normal]
"A-h" = "move_char_left"
"A-d" = "move_line_down"
"A-r" = "move_line_up"
"A-n" = "move_char_right"
[keys.select]
"A-h" = "extend_char_left"
"A-d" = "extend_visual_line_down"
"A-r" = "extend_visual_line_up"
"A-n" = "extend_char_right"That way does provide movement my holding the left alt key and pressing the physical h/j/k/l but it also uses up those alt+key combos. The one advantage over a complete layout change this has is that I can still use 'd' to 'd'elete while alt+d (which is the physical 'j' key) moves my cursor etc. |
im-select is helpful when you mostly use non-latin layouts (I'm not programmer but notetaker).
for such case I use remapped CAPSLOCk to Hyper and 'Hyper + <homerow_keys>' as arrows. It works everywhere in PC ) |
|
By the way, before Helix does the proper thing and implements a more convenient native support for alternative keyboard layouts you could use a couple of Python scripts to extend/replace your config to an alternative keymap |
But that's not a solution, e.g., if you have a visible keyboard selection indicator, it will constantly flash despite the fact that you don't really change any layout |
neither does But you're right that it should be flexible so that people who value mnemonics over physical location could continue to do so By the way, WezTerm has this cool feature that allows you to pick the mode on a per-key basis
https://wezfurlong.org/wezterm/config/keys.html#physical-vs-mapped-key-assignments |
|
Well the point of h/j/k/l is indeed to become "muscle memory" but it also mirrors the layout of arrow keys on older terminal keyboards and is mainly intended to keep your right hand on the homerow instead of having to move it all the time. However literally all other keys are mnemonics matching the action they perform. Not using keys in your native layout is extremely crippling to your muscle memory training because it forms from associating things like "Insert" or "Go Home" or "Delete" - an action with a matching letter - with a muscle movement. Things which you sabotage by having zero relation between the key, and the action it triggers. Alas.. we're derailing the topic. |
Same principle - you chose a more convenient location instead of relying on a keycap match
you're not crippling it for the same reason
The relation is not zero, it's just not keycap-based. For example,
Well, scan codes are a solution to this very topic, and they are a better solution than the workaround I've posted above since they also work for symbol keys and don't pollute the popup window, but you're arguing against them based on the value of keycap-based mnemonics |
|
An idea: #9896. |
While this is a valid idea it would still require that 'minor' normal mode to use scancode based input or translate the keys to scancodes on the fly in order to be able to act on key positions instead of the received character. Otherwise youre asking to provide a mapping for every possible keyboard layout in existence and any that might crop up in the future or are in use by people that make their own. That's pretty much exactly why ViM has langmap which was suggested a number of times already.. it allows you to switch an arbitrary number of pairs of keys but only while normal mode is active. |
|
@HealsCodes, I would not mind some kind of configured automated |
|
"not the case" is a wide stretch - I've been using it in ViM for over a decade and it works in combination with langnoremap. If you were to implement this feature in recent days you would probably use unicode-codepoints or actual scancodes for the langmap syntax to begin with ^^' |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
and others
this bug is thousands of years old, it is present in vi / vim / nvim / any vim-like editors I have tried and in the post-modern editor it is also present. This is super sad.
It must use key-codes, not key-chars or key-chars must be translated to key-codes on the fly.
Affected any national non-English and non-CJK layouts
The text was updated successfully, but these errors were encountered: