Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

bug: normal mode hardcoded with english layout #133

Closed
whoizit opened this issue Jun 5, 2021 · 67 comments
Closed

bug: normal mode hardcoded with english layout #133

whoizit opened this issue Jun 5, 2021 · 67 comments
Labels
A-keymap Area: Keymap and keybindings C-discussion Category: Discussion or questions that doesn't represent real issues C-enhancement Category: Improvements E-help-wanted Call for participation: Extra attention is needed E-medium Call for participation: Experience needed to fix: Medium / intermediate

Comments

@whoizit
Copy link

whoizit commented Jun 5, 2021

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

@whoizit whoizit changed the title normal mode hardcoded with english layout bug: normal mode hardcoded with english layout Jun 5, 2021
@kirawi

This comment was marked as outdated.

@whoizit
Copy link
Author

whoizit commented Jun 5, 2021

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.

@kirawi

This comment was marked as outdated.

@itzmjauz
Copy link
Contributor

itzmjauz commented Jun 6, 2021

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

@archseer
Copy link
Member

archseer commented Jun 6, 2021

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.

@pickfire
Copy link
Contributor

pickfire commented Jun 6, 2021

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?

@Kethku
Copy link
Contributor

Kethku commented Jun 27, 2021

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

@pickfire
Copy link
Contributor

pickfire commented Jun 28, 2021

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>.

@archseer
Copy link
Member

archseer commented Aug 2, 2021

showkey --scancodes internals: an ioctl call can set KDSKBMODE to RAW for scancodes (MEDIUMRAW to get keycodes again)

@blaggacao
Copy link

blaggacao commented Aug 2, 2021

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 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.

@whoizit
Copy link
Author

whoizit commented Aug 2, 2021

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

@blaggacao
Copy link

blaggacao commented Aug 2, 2021

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 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

@archseer
Copy link
Member

archseer commented Aug 2, 2021

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.

@whoizit
Copy link
Author

whoizit commented Aug 2, 2021

by the way, someone may not use the us layout at all, never

@blaggacao
Copy link

blaggacao commented Aug 2, 2021

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. 😺

@blaggacao
Copy link

blaggacao commented Aug 2, 2021

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. 😅

@kirawi kirawi added A-keymap Area: Keymap and keybindings C-enhancement Category: Improvements C-discussion Category: Discussion or questions that doesn't represent real issues labels Aug 19, 2021
@voroskoi
Copy link
Contributor

voroskoi commented Sep 5, 2021

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?

@gagbo
Copy link

gagbo commented Oct 29, 2021

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 ctsr for hjkl, the keycodes for ctsr are still 43..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

@pickfire pickfire added the E-help-wanted Call for participation: Extra attention is needed label Oct 30, 2021
@kirawi
Copy link
Member

kirawi commented Nov 2, 2021

I don't know if it's possible, but maybe we could provide that above function within Helix?

@pickfire
Copy link
Contributor

pickfire commented Nov 2, 2021

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.

@blaggacao
Copy link

I do a continue to do custom build for this. thanks to flake.nix that's easy.

@koiuo
Copy link

koiuo commented Jun 23, 2022

BTW, there is nothing about quotes in the docs:

you are looking at the wrong docs https://toml.io/en/v1.0.0#keys

Bare keys may only contain ASCII letters, ASCII digits, underscores, and dashes (A-Za-z0-9_-).

Quoted keys follow the exact same rules as either basic strings or literal strings and allow you to use a much broader set of key names.

@HealsCodes
Copy link

Just another voice for a properly implemented langmap-like feature.
Contrary to the comments about it being a crutch.. it's not if you use it correctly and it works on any WM and any platform that has a vim.

langmap is accompanied by an additional command called langnoremap in vim/nvim. The later being responsible for preventing keys issued by plugins to be remapped. With that you can very easily fix your non-insert-mode to work for most layouts without breaking functionality.

" 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

sinefabula pushed a commit to sinefabula/helix that referenced this issue Dec 7, 2022
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.
sinefabula added a commit to sinefabula/helix that referenced this issue Dec 7, 2022
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.
@vwkd
Copy link
Contributor

vwkd commented Dec 10, 2022

+1

VSCode gets this right.

Currently, helix needs an additional two keystrokes for every input to switch to / from foreign language.

@idoric
Copy link

idoric commented Dec 15, 2022

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.

@soloturn
Copy link

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.
https://crates.io/crates/keyboard_query

@HealsCodes
Copy link

HealsCodes commented Mar 15, 2023

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. https://crates.io/crates/keyboard_query

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.

@soloturn
Copy link

soloturn commented Mar 16, 2023

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

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?

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 _I_nsert mode on a dvorak layout would - for example - require pressing 'c' (which is the physical 'i' key) and that makes mnemonics completely useless.

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?

@HealsCodes
Copy link

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

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?

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..

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.

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)

@ZabejAga
Copy link

ZabejAga commented May 2, 2023

There is a solution for the (n)vim/kak/VScodeVIM editors : plugins like im-select.
It will change layout to defined (i.e. 'US') when you change mode to normal.
Would be nice to have such solution here as it solves(at least part of) the issue.

@HealsCodes
Copy link

HealsCodes commented May 5, 2023

There is a solution for the (n)vim/kak/VScodeVIM editors : plugins like im-select. It will change layout to defined (i.e. 'US') when you change mode to normal. Would be nice to have such solution here as it solves(at least part of) the issue.

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.

@ZabejAga
Copy link

ZabejAga commented May 18, 2023

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.

im-select is helpful when you mostly use non-latin layouts (I'm not programmer but notetaker).

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 :|

for such case I use remapped CAPSLOCk to Hyper and 'Hyper + <homerow_keys>' as arrows. It works everywhere in PC )

@eugenesvk
Copy link

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

#7097

@eugenesvk
Copy link

There is a solution for the (n)vim/kak/VScodeVIM editors : plugins like im-select

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

@eugenesvk
Copy link

Call me wrong but 'c' doesn't really associate mentally with 'Insert', does it?

neither does h associate with left. Mnemonics aren't useful for such frequent keys as cursor movements or switching to insert mode, your muscle memory will very quickly map it to a finger, not a keycap (thus it's best to use a better key position), so being able to have consistent physical mappings is a plus of scancodes

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

You can explicitly assign using the physical position by adding a phys: prefix to the value, for example: key="phys:A". This will match key presses for the key that would be in the position of the A key on an ANSI US keyboard.

https://wezfurlong.org/wezterm/config/keys.html#physical-vs-mapped-key-assignments

@HealsCodes
Copy link

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.
The whole reason being that it helps you learn the action by deducing the keys from what you want to do.

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.

@eugenesvk
Copy link

mainly intended to keep your right hand on the homerow instead

Same principle - you chose a more convenient location instead of relying on a keycap match

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.

you're not crippling it for the same reason jkl does not - keycap associations don't provide much over repetition, which is plenty for these commonly used keys like Insert. And then there are too many commands that start with some letter for you to have a unique association (how does D delete, left or right? with or without yank, where would decrement command go?)

Things which you sabotage by having zero relation between the key, and the action it triggers.

The relation is not zero, it's just not keycap-based. For example, H is positioned to the left, and home is positioned to the left, so here is your association - you move your finger off home keys to the left to move further left (or I'm using h as backspace with a similar direction-based mnemonic)

Alas.. we're derailing the topic.

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

@alexeymuranov
Copy link

An idea: #9896.

@HealsCodes
Copy link

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.

@alexeymuranov
Copy link

alexeymuranov commented Mar 17, 2024

@HealsCodes, I would not mind some kind of configured automated langmap for both my 'major' and 'minor' normal modes. As long as it works. (Which is not the case in Vim: vim/issues/3018, vim/issues/5147.)

@HealsCodes
Copy link

"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.
Not surprised it wasn't implemented with multibyte characters back in the day (you have to account for the age of ViM, proper unicode support came way after).

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 ^^'

@helix-editor helix-editor locked and limited conversation to collaborators Apr 7, 2024
@pascalkuthe pascalkuthe converted this issue into discussion #10228 Apr 7, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
A-keymap Area: Keymap and keybindings C-discussion Category: Discussion or questions that doesn't represent real issues C-enhancement Category: Improvements E-help-wanted Call for participation: Extra attention is needed E-medium Call for participation: Experience needed to fix: Medium / intermediate
Projects
None yet
Development

No branches or pull requests