bug: normal mode hardcoded with english layout

[whoizit]

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]

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.

[itzmjauz]

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]

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]

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]

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]

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]

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

[blaggacao]

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.

[whoizit]

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]

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]

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]

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

[blaggacao]

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

[ZabejAga]

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]

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]

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]

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]

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]

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]

An idea: #9896.

[HealsCodes]

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]

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

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

[VKondakoff]

Hey, hey...

Now it is not a bug, but discussion. So, here is a question: are there any plans to allow using Helix with non-Latin keyboard layouts? As far as I can see currently it is almost impossible: when you switch to a non-Latin keyboard layout all of the keys in all of the Helix modes just stops to work.

For more than three years this issue is just ignored. Does this means, that Helix is an editor for people, who use Latin keyboards only? I'm really interested to hear the devs: are they aware of this? Are there any ideas of how this can be fixed? What is the devs vision of this issue?

Thank you!

[kirawi]

Issues are more about tracking specified features and bugs whereas discussions are less clear.

[feelamee]

this is not a fix, but working solution:

[keys.insert]
"esc" = [":run-shell-command hyprctl switchxkblayout at-translated-set-2-keyboard 0 &>/dev/null", "normal_mode"]

use your command to switch layout after :run-shell-command

[HealsCodes]

Only if you happen to work on linux (1/3rd of the platforms helix is supported on) and also only if you don't edit remote - it does nothing for a remote editor inside of an ssh session :(

[feelamee]

I'm not sure, but Windows and MacOS also should support this? MacOS anyway)
ssh, unfortunately, will not(

[VKondakoff]

I was heard there is a way to fix the layout issues with tools like Kmonad/Karabiner (using their mod-tap and layer functions). Is there anyone, who tried to implement this? Any instructions?

[idoric]

Right now I'm trying https://github.com/OneDeadKey/arsenik.

[estin]

Hi! Another one seeker for solution. That's my solution based on some ideas above.

On command mode and jump-to-word:

• fetch scancode via keyboard_query
• and make new KeyEvent based from original KeyEvent and scancodes

Tested only on linux (xlib) and qwerty keyboard.

https://github.com/estin/helix/tree/scancode (from current master)

cargo install --features scancode --locked --path helix-term

And add to the yours helix config

[editor.scancode]
layout = "qwerty"

# https://github.com/rsaarelm/scancode-rs
# https://www.millisecond.com/support/docs/current/html/language/scancodes.htm
# https://kbdlayout.info/kbdusx/scancodes
# https://github.com/LuaDist/sdl/blob/master/include/SDL_scancode.h
[editor.scancode.map]
qwerty = [
  [1, ["esc"]],
  [2, ["1", "!"]],
  [3, ["2", "@"]],
  [4, ["3", "#"]],
  [5, ['4', '$']],
  [6, ['5', '%']],
  [7, ['6', '^']],
  [8, ['7', '&']],
  [9, ['8', '*']],
  [10, ['9', '(']],
  [11, ['0', ')']],
  [12, ["-", "_"]],
  [13, ['=', "+"]],
  [14, ['backspace']],
  [15, ['tab']],
  [16, ['q']],
  [17, ['w']],
  [18, ['e']],
  [19, ['r']],
  [20, ['t']],
  [21, ['y']],
  [22, ['u']],
  [23, ['i']],
  [24, ['o']],
  [25, ['p']],
  [26, ['[', '{']],
  [27, [']', '}']],
  [28, ['ret']],
  [29, ['leftcontrol']],
  [30, ['a',]],
  [31, ['s',]],
  [32, ['d',]],
  [33, ['f',]],
  [34, ['g',]],
  [35, ['h',]],
  [36, ['j',]],
  [37, ['k',]],
  [38, ['l',]],
  [39, [';', ':']],
  [40, ["'", '"']],
  [41, ['`', '~']],
  [42, ["leftshift"]],
  [43, ['\', '|']],
  [44, ['z']],
  [45, ['x']],
  [46, ['c']],
  [47, ['v']],
  [48, ['b']],
  [49, ['n']],
  [50, ['m']],
  [51, [',', '<']],
  [52, ['.', '>']],
  [53, ['/', '|']],
  [54, ['rightshift']],
  [55, ['printscreen']],
  [56, ['leftalt']],
  [57, ['space']],
  [58, ['capslock']],
  [59, ['F1']],
  [60, ['F2']],
  [61, ['F3']],
  [62, ['F4']],
  [63, ['F5']],
  [64, ['F6']],
  [65, ['F7']],
  [66, ['F8']],
  [67, ['F9']],
  [68, ['F10']],
  [69, ['numlock']],
  [70, ['scrolllock']],
  [71, ['home']],
  [72, ['up']],
  [73, ['pageup']],
  [74, ['-']],
  [75, ['left']],
  [77, ['right']],
  [78, ['+']],
  [79, ['end']],
  [80, ['down']],
  [81, ['pagedown']],
  [82, ['ins']],
  [83, ['del']],
]