Add support for non-QWERTY keyboard layout

[liferooter]

There are people who uses some alternative keyboard layout since QWERTY is uneffecient and unconvenient. It usually improves the quality of their life. There are also people who uses Helix editor since other editors are less powerful and less post-modern. It usually improves the quality of their life too. Unfortunately, there are no people who can get benefits of these both life improvements, since Helix doesn't support alternative keyboard layouts and doesn't allow to remap everything (well, it allows to remap something, but not everything).

It's also kind of hell to remap everything manually in other editors, like Vim. You have to remap the same keys again and again with different modifiers and in different modes (like hjkl to neio in Colemak). So I suggest to add some alternative keyboard support. For example, allow to remap everything and also add some options to mass-remap movement keys in all shortcuts that uses them.

P.S. Can't wait to be able to use Helix with my Colemak keyboard layout.

[CptPotato]

There is a relevant PR for this: #5046

But I'm not sure if a decision was made whether or not that's a favorable approach.

[kirawi]

Duplicate of #133

[liferooter]

No. #133 is about that hotkeys don't work on non-English layouts. It's about an ability to use more than one layout in Helix. This issue is about that the only supported English layout is QWERTY. A solution for #133 is to translate non-English keys into English, a solution for this issue is to allow to easily remap English-based hotkeys to make Helix usable on non-QWERTY English layouts. This two issue are not the same.

[the-mikedavis]

Most of the key bindings are based on memorability instead of keyboard positioning (for example: d deletes a selection, c changes a selection) so remapping may not be necessary even if you're using a different layout. I use dvorak and do not remap any keys and I know that some of the other maintainers use other layouts too without any remapping.

[liferooter]

How do you live with hjkl on Dvorak?

[the-mikedavis]

The hjkl positions on dvorak are in pretty comfortable and memorable spots. I just use them as-is

[liferooter]

hjkl in Dvorak are hynu in QWERTY. Also Colemak is home-row-centric layout, so using keys on the same positions as hjkl on QWERTY is inconvenient too

[cd-a]

I'm on ColemakDH and use the standard keybindings. I thought hard about remapping everything a year ago in vim, especially hjkl, but since I wanted to use those keys less anyway, I figured it's fine.

After over a year, and it's going great. There was a big thread on hackernews a while back, where most people said the same thing, just use it as is and it works great.

Your mileage may vary, of course, so I think it would be helpful to implement support for different layouts. Just wanted to share that it works very well without any remap if you want to give it a shot.

[Jummit]

Just wanted to chime in and say that I'm using dvorak with default mappings in Vim and Helix for a couple of years. It's really not that big of a difference to QWERTY, and remapping everything breaks mnemonics and is hard to maintain when adding plugins with custom bindings.

There is software where I choose to remap everything, such as Krita and Blender. What's different with these is that I can only have my secondary hand on the keyboard, and that limits which keys I can press.

[templateK]

The hjkl positions on dvorak are in pretty comfortable and memorable spots. I just use them as-is

There are people uses non-standard keyboard layout. The HJKL keys on my English keyboard layout is not uncomfortable but it would feel awkward to use these keys for movement since J is on left index finger HK is pressed with right index finger and L is assigned to right thumb.

I will be really appreciated if this feature is implemented as many others who uses alternative keyboard layouts.

[archseer]

Helix doesn't support alternative keyboard layouts and doesn't allow to remap everything (well, it allows to remap something, but not everything).

We allow remapping everything. If you find something not remappable it's a big.

I wrote Helix and I also use a different layout (Norman) and simply got used to the new hjkl locations. Maintaining completely different keybinding sets per layout would be a headache, instead I propose that you come up with a modified layout as a key bind configuration and share it on the wiki.

(#5033 could also solve this by using the same key positions)

[icecreammatt]

We allow remapping everything. If you find something not remappable it's a big.

Does this include enter match mode? I'd like to swap it with h so I don't have to move my finger left to enter it when using Colemak-DH but from the sites docs it doesn't appear to be possible. ( Says N/A ) I use unei as my arrow keys but mapped on a different layer so I can keep most of the original bindings on the home layer.

[liferooter]

We allow remapping everything. If you find something not remappable it's a big.

I've just checked. According to Helix docs, remapping is currently not supported for:

• Picker
• Prompt

Wow. When I checked previous time, more bindings was non-remappable. Thank you very much. Picker and prompt have no keys that I would really appreciate to remap, so now I can try to remap Helix for Colemak.

It still would be good to have some centralized setting for hjkl or something like this to remap everything more easily, but it works!

[mattmc3]

As a Colemak user, I ran across this issue. While built-in support for alternative layouts might be beneficial, there is a lot of nuance to this (what layouts are supported? Dvorak? Colemak? Colemak-DH? Canary? Carpalax? Workman? Where does it end? Who supports the layout features? etc). Also, there's also quite a bit of personal preference involved - Colemak HNEI or UNEI for arrows? QWERTY in normal mode and alternative layout in insert mode, or just partial support? What about window movement? Goto mode? Should it all be remapped?

I think it may be best for the alternative layout communities to collaborate on a set of (or multiple sets of) mappings and share those configs rather than bake this into Helix. This is also one more vote for getting a plugin system worked out ASAP, which would make sharing these a lot easier.

For now, here's a simple set of remaps that have worked for me in the interim while this issue is being decided. It borrows from emacs-evil-colemak-basics.

[keys.normal]
# -------------------------
# QWERTY to Colemak remaps
# [JY] [LU] [UI] [..]
#  [..] [NJ] [EK] [IL]
#   [KN] [..] [..] [..]
# -------------------------
# N <=> K (swap, QWERTY position)
n = "move_line_down"
N = "keep_selections"
k = "search_next"
K = "search_prev"
# E <=> J (swap actions)
j = "move_next_word_end"
J = "move_next_long_word_end"
e = "move_line_up"
E = "join_selections"
# ILU loop
# I => L
i = "move_char_right"
I = "no_op"
# U => I (QWERTY position)
u = "insert_mode"
U = "insert_at_line_start"
# L => U (QWERTY position)
l = "undo"
L = "redo"

Or, you can use UNEI -

# N <=> K (K is in the QWERTY N position)
n = "move_char_left"
N = "keep_selections"
k = "search_next"
K = "search_prev"
# E <=> J (J now 'jumps words')
e = "move_line_down"
E = "join_selections"
j = "move_next_word_end"
J = "move_next_long_word_end"
# H <=> I (H is just a sideways I)
i = "move_char_right"
I = "no_op"
h = "insert_mode"
H = "insert_at_line_start"
# U <=> L (L is in the QWERTY U position)
u = "move_line_up"
U = "no_op"
l = "undo"
L = "redo"

[liferooter]

Yes, I think we need some easy and convenient way to remap everything, not some built-in support for every layout. Also I've checked recent Helix version and now I see that it's finally possible to remap almost everything and also it's easy to remap all the keys, much easier than in Vim. So I think this issue must be closed when fully everything will be remappable.

[soloturn]

to be honest i would prefer for the command mode to use the scancode or keyid instead of remappings. french bepo, swiss german or swiss french keyboards have a dead key on the english ] position.

something in the lines of this tiny library.
https://crates.io/crates/keyboard_query

[clarfonthey]

This is a pretty hard blocker for me ever using helix, since via both vim and kakoune I can easily remap keys regardless of context, which I've done here: https://codeberg.org/clarfonthey/laymap

Unfortunately, this is just not possible via Helix, which makes it unusable for me. I get how some people have just adopted the keys in their own native layouts, but IMHO it's much easier to simply rely on the QWERTY-native positions while still being able to type in the native layout. While #5046 isn't perfect, it would provide the ability to at least use Helix like I use Vim & Kakoune right now, by learning the native positions.

And for anyone who might say this: yes, I could manually add in key remappings for every single existing command to the new bindings. This is impractical (easy to make mistakes), unmaintainable (if new commands are added, they have to be added to this list), and expects users to workaround something that quite frankly, should be a feature anyway.

I don't expect Helix to maintain its list of keyboard layouts to add "easy" settings to remap layouts, but I expect the ability to do so without having to enumerate every command available. This means that I can effectively configure my layout once and ensure it will work without having to account for new commands or changes in updates.

[kirawi]

The PR you linked is just waiting on review.

[cichan02]

Hey, community this is my full remap for Colemak.

I didn't improve something, no! Just automatic transfer from QWERTY to Colemak. I suppose you will use this file as base for further improvements)))

config.txt

[clarfonthey]

The PR you linked is just waiting on review.

Right, it's been waiting on review for over a year. I was pointing out just how absolutely necessary this feature is for people who don't use QWERTY keyboard layouts, and that it should be given a higher priority.

"Just waiting on review" is also incredibly misleading to say since you made this comment in October and the last mention of the PR was in April, despite hundreds of commits being made since then.

[kirawi]

You have to understand that there are many other PRs in queue and that there are only a few maintainers who are working on a volunteer-only basis.

[dead10ck]

@clarfonthey check yourself. Nobody owes you anything. We do this in our spare time for fun. You don't get to tell us what we should prioritize.

As of this writing, there are 815 open issues and 326 open PRs, and only 3-4 regular contributors. Do you know how many times a week we hear "X missing feature is critical and the only thing stopping me from using helix!"? We don't prioritize based on the number of demands an issue gets. In fact, if anything, posts like yours tend to push it further down the queue.

[clarfonthey]

Right, I know exactly what it's like to be asked to do thankless open source work, and I know that the entire community is run by volunteers. Except, it's not just a fun little text editor designed to be used solely by its creators: the fact that the project has a logo, a website, and has been advertised as a revolutionary new text editor built in Rust means that you clearly want it to be something that's used by everybody. Since accessibility is literally the reason why this morphed from a small text editor meant to be used by one person to a large project, I think it's reasonable to call out when accessibility issues are ignored.

From the bottom up, this project was not designed to be used by everybody. It was designed to be used by people who use QWERTY keyboards, which is seen as everybody by the developers, but is actually excluding a large portion of the world and forcing people to either settle for worse control schemes or maintain large configs so they can use it themselves.

The PR listed has been open for over a year and is a very, very small change. Most of the change is actually in documentation, which is admittedly real work that's difficult too.

The longer it's not merged, the more new features get adopted into the program without other keyboard layouts in mind, and the more work that's required to integrate it later.

Like, again, you owe me nothing. But it's still worthwhile to call out the fact that a change that has massive accessibility implications, is extremely simple, and has been waiting in limbo for over a year despite other changes. That shows that you don't understand what it means to develop a community, only a software project.

I honestly love everything about Helix, except this. I could see it replacing Kakoune as my daily driver and personally contributing lots of changes and helping with code review. Except, instead, people are calling me entitled for asking that simple accessibility issues be prioritised instead of sitting in limbo for over a year, despite active development otherwise. I'm not even asking you to merge it now! Just, that there's clearly something more going on here than "it's behind in the queue."

Like, these aren't simple issues of taste. Asking for more advanced LSP support, new editor features, whatever, is just being entitled. It takes time to develop something and I don't expect you to do everything for me when I ask. This is something that is full stop preventing people from using and investing time and effort into the project and its community. I get not coming up with proper solutions to these by yourself since they're hard problems to solve! I get hoping you could get the "right" solution before merging something new. But ultimately, having nothing is the wrong answer, especially when simple solutions are handed to you already finished and have been sitting around for a year.

Check yourself.

[kirawi]

I understand that it is a frustrating experience, but the reality is that there is usually no singular reason any particular PR has not been reviewed or merged. Sometimes it might be that we have an idea of what major changes we want to make for the next release. Other times it may be that we are blocking the change on some considerations that require non-trivial deliberations and solutions. Most of the time, it's really that the maintainers have a limited bandwidth on what they can review at any given moment.

I think you would have encouraged a positive dynamic if you had began by simply asking, "Hey, I've been waiting on this feature for a while now. I heard that it was waiting on a review a few months ago, and that still looks to be the case. What's the situation?" Speculating that there are reasons beyond the PR waiting on review does not give us the benefit of the doubt.

[the-mikedavis]

Most of the change is actually in documentation

Actually all non-Rust changes come from a bad merge commit, those aren't original changes. The PR currently adds no docs.

Plus #5046 doesn't actually do what you think it does. A map like:

[[editor.layout-remap]]
# qwerty
from = "qwertyuiop[]asdfghjkl;'zxcvbnm,./"
# dvorak
into = "',.pyfgcrl/=aoeuidhtns-;qjkxbmwvz"

only remaps [ and ], the rest are removed by https://github.com/sinefabula/helix/blob/f327a91602aedb727628af72e79886a0f7a9aea4/helix-view/src/editor.rs#L96-L107. It also introduces some unused functions and needs to be documented, so it definitely needs some work before it's mergeable.

I'll give it a review soon now that I've looked into it a little but I'm not convinced we need it. Remapping each command is certainly a rough workflow but IMO it's workable. I see this being solved in the long run via scripting. Once we can control config with scripting it should be possible to map over the keys in the keymap and replace the characters using a hashmap, somewhat similar to what you've done with Kakoune.

From the bottom up, this project was not designed to be used by everybody. It was designed to be used by people who use QWERTY keyboards, which is seen as everybody by the developers

See #5520 (comment). The original author and the majority of maintainers don't use qwerty.

[clarfonthey]

Right, and I apologise that I assumed negatively of you in my response back. The reason I made my initial response was to bring visibility to the fact that this is a larger issue than it might appear at the surface, and that it's not an unsolved problem; a PR already exists and has been hanging around for a while. I understand that especially with such a small number of people, it's easy for things to slide under the radar, and just wanted to clarify that I do think that merging an "okay" solution before fully fleshing out what keyboard remapping would look like in an ideal world would be worth it.

This is also why I commented here instead of on the PR; I didn't have the time to fully verify that the PR could be merged as-is (it is a year old, after all) and wanted to mention here in case someone else felt like taking the time to make an updated version.

Your response basically felt to me like you completely ignored everything I said and were choosing to not merge it, even though I shouldn't assume the worst of people. Like… the entire point of my comment was to say, when someone next gets time to think about this, I would prefer that a simple PR like the one described be merged, instead of debating on how it should specifically look for some ideal world. In my mind, literally the time you could have spent writing that comment could have been better spent on reviewing the PR, since you added no useful information.

That's why I assumed so negatively of you. I have encountered several people in my time who run open-source projects with a double-standard: I want all of the clout for being known as The Guy who made this cool thing, but simultaneously you are not allowed to ask for me to change any of my opinions on the thing that I'm showing everyone because it's mine. It's just so toxic and so prevalent, I assumed bad faith because assuming good faith just gets tiring after a while.

Especially with @the-mikedavis' comment which popped up as I was writing this, it seems clear that there are more issues with the existing PR, that it's not as simple as it looks, and that it is in fact stale after sitting around for a year. I interpreted it as "it's just waiting for review" as "it'll be an easy merge, once I look at it, which I am refusing to do right now," which is not what you said, but also something I have heard more directly so many times.

It makes a lot of sense that people supporting the text editor and investing a lot of time in it are fine with loads of tweaks to the keymappings to better support their layouts, because they know everything about it. I shouldn't have assumed that, and I'm sorry I did. The point still stands that for most people, learning a new modal text editor takes a lot of time and patience, and the requirement to map every single possible action, constantly keep up to date with the new features, etc. is just not worth it at all, and some solution would ease that pain a lot.

[kirawi]

In my mind, literally the time you could have spent writing that comment could have been better spent on reviewing the PR, since you added no useful information.

To clarify, I am not a maintainer. I am only responsible for triage and generally try to answer common questions and help with troubleshooting. While I can and have reviewed some PRs, I generally choose not to because I do not feel comfortable approving or discussing changes outside of what I have personally worked on in the past. I simply don't feel qualified.

[0x61nas]

The hjkl positions on dvorak are in pretty comfortable and memorable spots. I just use them as-is

how about dvorak-left?

[estin]

This new PR #10977  allows to configure scancode to keycode mapping.

For non-qwerty or non-English users, it means they can use Helix qwerty keymap as is.
But it requires a desktop environment to query keyboard state and won't work on ssh sessions.

[HighPriest]

At least for windows & in local terminal, this seems to be achievable with this PR & a custom keyboard layout created using Microsoft Keyboard Layout Creator.

Because windows is still reporting the same scan codes, no matter the layout, we could keep the normal bindings of QWERTY in NORMAL modes, while INSERT mode could insert key codes from custom layout.

I am trying to build helix with the mentioned PR & report back.