implement keyboard layout remapping #5046

sinefabula · 2022-12-07T15:02:47Z

This patch adds a config option to remap keys from a different keyboard layout into English so that keybindings work even with the keyboard switched into a non-English 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.:

[[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. Naming (from and into) is chosen to be of the same length so that the letters are aligned when using a monospace font, and the config is easier to write.

These translation mappings are applied in every mode except for (obviously) the Insert mode.

This circumvents #133 in a way that while Helix still does not recognise keypresses by their scan-codes but yet it allows for the non-English layout users to operate the editor without switching the layout which can be especially useful for writing documentation in their native language with Helix.

One caveat with this patch is that you can't remap keys already present in the English layout because Helix is not aware of the current keyboard layout and will apply translation every time, thus messing with the original mapping. This patch prevents such behaviour by disabling corresponding bindings and reporting these cases to the Helix log file. The other option would be to fail but I thought it would be safe to just filter them and log it.

A complete configuration example for macOS ISO keyboard layout looks like this. I've been using this for over a month now and it works great. Of course it is not the best solution of #133 but it does like 80% of the job, covering most used cases.

[[editor.layout-remap]]
from = '<!"№%:,.;()_+'
into = '±!@#$%^&*()_+'

[[editor.layout-remap]]
from = 'йцукенгшщзхъЙЦУКЕНГШЩЗХЪ'
into = 'qwertyuiop[]QWERTYUIOP{}'

[[editor.layout-remap]]
from = 'фывапролджёФЫВАПРОЛДЖЭЁ'
into = 'asdfghjkl;\ASDFGHJKL:"|'

[[editor.layout-remap]]
from = 'э'
into = "'"

[[editor.layout-remap]]
from = ']ячсмитьбю/[ЯЧСМИТЬБЮ?'
into = '`zxcvbnm,./~ZXCVBNM<>?'

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.

SoraTenshi · 2022-12-12T10:43:34Z

My 2 cents:
I don't really think the way this is configured is optimal, i would love to have a clear distinction between which row is being remapped.

Something like this:

[[editor.layout-remap-r1]]
from = '<!"№%:,.;()_+'
into = '±!@#$%^&*()_+'

[[editor.layout-remap-r2]]
from = 'йцукенгшщзхъЙЦУКЕНГШЩЗХЪ'
into = 'qwertyuiop[]QWERTYUIOP{}'

etc.

idoric · 2022-12-15T13:46:40Z

I'm using the bépo layout (some kind of french dvorak), and where you find the y on a qwerty layout there is a dead key (which doesn't generate a character by itself) on the bépo. Am I mistaken in thinking that this PR would not solve this scenario?

Also, I don't understand what the caveat is.

AmitDIRTYC0W · 2023-02-06T21:40:16Z

Will this be merged any time soon? I'm waiting to switch to Helix and Workman support is the dealbreaker

BreakingLead

I've tested, it works great.
So will this be merged?

soloturn · 2023-03-15T08:19:56Z

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, also described a little in #133.

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

sinefabula · 2023-03-17T19:34:03Z

@SoraTenshi I'm afraid I don't get your point on explicit row mapping. Why would you want that? I just allowed the user to split the mapping into sections for easier reading and writing; these sections do not have to be rows. I'm coming from vim here where you can't do this and you end up with a really long langmap line which is very hard to fix if there's a mistake.

@idoric I guess you're right, dead key won't generate a keystroke therefore I don't think you'd be able to remap it this way. This whole remapping thing, it's still a hack, a good one (in my opinion at least), but a hack nevertheless!

@BreakingLead glad it worked for you too! I'm using it for several moths straight and have zero problems. It's quite a simple piece of code actually.

@soloturn yeah you're right, I'd very much prefer that too. I just didn't see that coming in any near future so I felt this workaround was essential for me (and perhaps many others who write in a language other than English). I'm not sure at the moment how hard it would be to implement these scancodes. I certainly would like to try it so thanks for pointing to the library. But I guess someone may have already tried this?

SoraTenshi · 2023-03-17T19:38:23Z

@SoraTenshi I'm afraid I don't get your point on explicit row mapping. Why would you want that? I just allowed the user to split the mapping into sections for easier reading and writing; these sections do not have to be rows. I'm coming from vim here where you can't do this and you end up with a really long langmap line which is very hard to fix if there's a mistake.

My idea here was to map it based around the actual, physical keyboard 'rows', so that there is not a real ambiguity.
However, this is just an idea I had.

soloturn · 2023-03-19T14:28:50Z

@sinefabula often only one dead key looks a challenge, though i think the PR should be merged.

for dead keys, i found another file with keylayouts and wonder if this would help specify a dead key in the from mapping? lets pick out one example, the diaresis dead key, on swiss german keyboard at the location of english right brace, ].

#define ASCII_5D	KEY_RIGHT_BRACE				// 93 ]

#ifdef LAYOUT_GERMAN_SWISS

#define DIAERESIS_BITS		0x0300
#define DEADKEY_DIAERESIS	KEY_RIGHT_BRACE
#define ISO_8859_1_EB	DIAERESIS_BITS + KEY_E			// 235 ë     e DIAERESIS  TODO: check this

links:

soloturn · 2023-03-24T07:14:28Z

@pascalkuthe anything missing to merge this?

pascalkuthe · 2023-03-24T11:24:10Z

I don't have merge permissions so mostly a review from @archseer. From my side tKS We have a lot on our plate right now as we are heading towards the next release but I am sure he will get to your PR eventually.

* changelog: Checkpoint 2023-01-10 commit: 927fa11 * changelog: Checkpoint 2023-02-05 commit: 9c98043 * changelog: Checkpoint 2023-03-17 commit: bd47392 * changelog: Checkpoint 2023-03-27 commit: 5323020 * Set a tentative release date for 2023-03-31 * Update CHANGELOG.md * Mention virtual text PR in inlayed type hints feature links * Fix description for 5097 * Rebalance features, usability improvements and fixes * Reorganize some out-of-place changes to the proper sections * Eliminate the LSP configurations section This has a lot of overlap with the 'new languages' section with newly supported LSP configurations. Smaller changes to LSP configurations are not so common so I folded those into the 'updated languages and queries' section.

the-mikedavis

I left some notes on the changes themselves but IMO this shouldn't be merged. It's something I imagine would be really trivial to do once we can script config: I'm imagining mapping over the keymap data structure and switching the characters using a hashmap - that's similar to how you'd do this in an editor like Kakoune. That would also be more flexible so that you could choose to apply these in any mode, for example only in insert mode. Also see #5520 (comment).

the-mikedavis · 2024-01-19T14:53:27Z

CHANGELOG.md

It looks like there is a problem with the merge commit - all of these changes are from the master branch and shouldn't be duplicated

the-mikedavis · 2024-01-19T14:59:07Z

helix-view/src/input.rs

+    /// `KeyCode::Char(c)` are translated. This method should be used
+    /// whenever a translation for the characters is desired, e.g. when
+    /// remapping a keyboard layout from non-Latin to Latin.
+    pub fn translate<F>(&self, f: F) -> KeyEvent


This is unused and can be removed

the-mikedavis · 2024-01-19T14:59:52Z

helix-term/src/keymap.rs

@@ -300,6 +300,32 @@ impl Keymap {
        res
    }

+    pub fn traverse_map<F>(&self, f: F)


This is also unused, can be removed

the-mikedavis · 2024-01-19T15:11:43Z

helix-view/src/editor.rs

+    pairs
+        .iter()
+        .filter_map(|(_, to)| pairs.contains_key(to).then(|| *to))
+        .collect::<Vec<_>>()
+        .into_iter()
+        .for_each(|c| {
+            warn!(
+                "Key '{}' removed from layout-remap as it would overwrite Latin layout binding",
+                c
+            );
+            pairs.remove(&c);
+        });


Is this part actually necessary? If you wanted to remap between keyboard layouts for example:

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

you would only rebind [ and ] since those are the only characters not duplicated between from and into. You only translate the incoming key event once so having duplication between from and into shouldn't matter - it won't cause some recursive loop of remapping.

the-mikedavis · 2024-01-19T15:14:27Z

helix-view/src/editor.rs

+struct LayoutMap {
+    from: String,
+    into: String,
+}


I'm very opposed to this representation. It's a lot of indirection to have a Vec<LayoutMap> turn into a HashMap<char, char> when we could just use a TOML table. This is less verbose than a TOML table but we don't really need to optimize for concise config - I would rather have it be explicit.

pascalkuthe · 2024-04-13T21:58:37Z

closing this as this pr has gone stale. As Mike already said I don't see us going forward with something like this in core. This should instead be covered by #10389 in the future.

Thank you for contributing!

sinefabula added 3 commits December 7, 2022 16:30

fix clippy warnings

3e55f83

remove unneeded example from helix-term

d86dcf1

pascalkuthe added C-enhancement Category: Improvements A-keymap Area: Keymap and keybindings S-waiting-on-review Status: Awaiting review from a maintainer. labels Dec 7, 2022

CptPotato mentioned this pull request Jan 13, 2023

Add support for non-QWERTY keyboard layout #5520

Closed

BreakingLead reviewed Feb 16, 2023

View reviewed changes

the-mikedavis and others added 4 commits March 31, 2023 15:21

Disable aarch64-macos build for now (build issues)

e59cb19

Fix AppImage build problems

3cf0372

Merge branch 'keyboard-layout-remap' into HEAD

f327a91

soloturn mentioned this pull request Apr 11, 2023

permit [keys.normal.ä] as config.toml table headers #6704

Closed

the-mikedavis requested changes Jan 19, 2024

View reviewed changes

the-mikedavis added S-needs-discussion Status: Needs discussion or design. and removed S-waiting-on-review Status: Awaiting review from a maintainer. labels Jan 19, 2024

sicher mentioned this pull request Mar 13, 2024

Better support for international keyboards #9862

Closed

pascalkuthe closed this Apr 13, 2024

clarfonthey mentioned this pull request Apr 14, 2024

tracking issue: Switch to a scheme based config #10389

Open

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

implement keyboard layout remapping #5046

implement keyboard layout remapping #5046

sinefabula commented Dec 7, 2022 •

edited

SoraTenshi commented Dec 12, 2022

idoric commented Dec 15, 2022

AmitDIRTYC0W commented Feb 6, 2023

BreakingLead left a comment •

edited

soloturn commented Mar 15, 2023 •

edited

sinefabula commented Mar 17, 2023

SoraTenshi commented Mar 17, 2023

soloturn commented Mar 19, 2023

soloturn commented Mar 24, 2023

pascalkuthe commented Mar 24, 2023

the-mikedavis left a comment •

edited

the-mikedavis Jan 19, 2024

the-mikedavis Jan 19, 2024

the-mikedavis Jan 19, 2024

the-mikedavis Jan 19, 2024

the-mikedavis Jan 19, 2024 •

edited

pascalkuthe commented Apr 13, 2024 •

edited

implement keyboard layout remapping #5046

implement keyboard layout remapping #5046

Conversation

sinefabula commented Dec 7, 2022 • edited

SoraTenshi commented Dec 12, 2022

idoric commented Dec 15, 2022

AmitDIRTYC0W commented Feb 6, 2023

BreakingLead left a comment • edited

Choose a reason for hiding this comment

soloturn commented Mar 15, 2023 • edited

sinefabula commented Mar 17, 2023

SoraTenshi commented Mar 17, 2023

soloturn commented Mar 19, 2023

soloturn commented Mar 24, 2023

pascalkuthe commented Mar 24, 2023

the-mikedavis left a comment • edited

Choose a reason for hiding this comment

the-mikedavis Jan 19, 2024

Choose a reason for hiding this comment

the-mikedavis Jan 19, 2024

Choose a reason for hiding this comment

the-mikedavis Jan 19, 2024

Choose a reason for hiding this comment

the-mikedavis Jan 19, 2024

Choose a reason for hiding this comment

the-mikedavis Jan 19, 2024 • edited

Choose a reason for hiding this comment

pascalkuthe commented Apr 13, 2024 • edited

sinefabula commented Dec 7, 2022 •

edited

BreakingLead left a comment •

edited

soloturn commented Mar 15, 2023 •

edited

the-mikedavis left a comment •

edited

the-mikedavis Jan 19, 2024 •

edited

pascalkuthe commented Apr 13, 2024 •

edited