helix
helix copied to clipboard
helix-editor
bug: normal mode hardcoded with english layout
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
To be fair, won't most programmers already be typing Latin characters? I also think most keyboards support Latin characters. But I'm genuinely interested in why you want this.
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.
You make a valid point, this should definitely be a feature. However, it's unclear to me why you wouldn't be able to use alternate mappings on vim/neovim/etc. I'd think this is probably the route Helix should go as well.
You make a valid point, this should definitely be a feature. However, it's unclear to me why you wouldn't be able to use alternate mappings on vim/neovim/etc. I'd think this is probably the route Helix should go as well.
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
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.
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 :keymap <keys>.
showkey --scancodes internals: an ioctl call can set KDSKBMODE to RAW for scancodes (MEDIUMRAW to get keycodes again)
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:
- https://docs.rs/evdev/0.11.0/evdev/
- https://docs.rs/evdev/0.11.0/evdev/struct.Key.html
A.f.a.i.r. and as the evdev rust docs say:
The Linux kernel’s “evdev” subsystem exposes input devices to userspace in a generic, consistent way.
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). Look how it works in sway:
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. https://github.com/swaywm/sway/wiki#key-bindings-on-a-dual-usrussian-layout swaywm/sway#5409
so i can do even so:
set $bindsym bindsym --to-code
$bindsym {
...
$mod+s layout stacking
$mod+w layout tabbed
$mod+e layout toggle split
...
}
all I changed from the default (us-only configuration) is bindsym replaced with bindsym --to-code and began to use $bindsym variable instead bindsym keyword. And it worked no matter what layout I'm on
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. :stuck_out_tongue_winking_eye:
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 evdev scan codes are the thing that comes closest to that. Only for the modal commands, that is, of course: for regular text input, surely use whatever is configured.
AFAIK key codes are constrained by those awful ASCII terminal constraints
But you're forgetting that not all keyboards have the same physical layout. I find sway's behavior acceptable because I can bind the thumb cluster based on my default layout without having to figure out scancodes for each key.
But you're forgetting that not all keyboards have the same physical layout.
Very true, I really just wanted to complement the discussion with a radically different angle in the hopes that this angle can make helix a radically better editor.
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. :smiley_cat:
just use classic keyboards by swiping diagonally across the keys and everything will be comfortable (peeped at a4tech anti-rsi keyboards). No separate keyboards needed, no a4tech keyboard needed, just regular keyboard enough and think a little.
http://www.compax.ru/bib/rsi/typeme.jpg
just use classic keyboards by swiping diagonally across the keys and everything will be comfortable
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. :sweat_smile:
That somewhat works, but it requires elbow movements for smaller hands.
I've been typing for so many years, I'm fine. Prior to that, he studied academic touch typing. It was hard and painful, then I came across a rhombic keyboard and realized what I was doing wrong. This method suits me. This is applicable for any conventional keyboard. I have the keyboard on my lap, slightly diagonally. the left side of the keyboard is closer to the body, the right side is farther away. (translated)
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(/) is SHIFT+6 for example, which is quite bad, but I haven't changed it as I have to press this for changing dirs and so too, using different keys seems strange. I could use us layout, but then I can not use accent keys (éáű etc.).
I have found https://github.com/samvel1024/kbct which seems a global solution for this problem. OTOH if I remap / to é for example, then I can not type é anymore, so this is just changing layout to us. What I would really use is something that lets me use my accent chars in insert-mode and use the same keys to search and so in normal mode, but with every program.
(Actually that still would not work, because I may have directories with accents chars in its name, so typing ~/é would be quite difficult when / is bould to é). Am I over-complicating this?
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:
- allow keycodes to be used in the (Rust) configuration, so that default configuration is still mostly "position based" for all keyboard layouts. (Even with my layout that has
ctsrforhjkl, the keycodes forctsrare still43..46, just mapped to different keysyms) - allow users to override bindings in TOML using either
- "natural" notation which would describe keys just like today
- "keycode" notation which would take the integer code values as keys for bindings
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 ^, finding becomes e...), but I'd rather deal with those on a case by case basis.
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, Gerry
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 flake.nix that's easy.
Hello! Are there any progress on this topic? Currently it is almost impossible to use Helix on a systems with two (or more) keyboard layouts: when you switch keyboard layout to a non-Latin one, the Normal mode stops to respond. There are several workarounds in Vim/Neovim intended to overcome this issue: langmaps, keymaps, xkb-switching. All of them have pros and cons. What are the Helix devs planning on this issue? (I hope Helix will not become an editor, which supports only Latin keyboard layout). Thanks!
Let me resend the same message.
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.
No progress on this until someone say they are working on this or someone submits a pull request. At least I don't think any of the contributors are very interested in this now, if people think it is important there should already be a patch by now.
Which is also why I labeled the issue as E-help-wanted.
@pickfire I guess you still not understand issue, dvorak it's english layout, but this issue about non-english layout's like russian, finnish, franch, italiano and thousands others
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
Can you, please, bring a little bit more light here? What are these tools? Is something landed? Thanks!
@pickfire I guess you still not understand issue, dvorak it's english layout, but this issue about non-english layout's like russian, finnish, franch, italiano and thousands others
Ah, now I get what you meant. Like uk or japanese keyboard (at least these are the ones I have seen) which have extra keys.
no, it's not about extra keys. You need to switch the layout to English in order to interact with the editor, that's what this is about.
This ⬆.
Here is a short video. I'm pressing a simple key sequence i<Esc>v<Esc>s<Esc> in Normal mode, while my keyboard layout is set to En, then I repeat the same keys when keyboard layout is set to Ru:
https://user-images.githubusercontent.com/230824/142721405-b179dabc-891b-4925-bfbf-bdb24790aa39.mov