Thanks for trying to help out. I haven't studied your code yet, but I like the idea of expanding this to support uXXXX. I always thought char_X was a bit limiting. Just one question below.

I don't quite follow the example in your motivation.

You can define a binding to ; with the existing config logic as well, the limitation is only imposed by the unquoted string, a ; semicolon will act as a statement separator so it only sees the char_.

(we may want to check our general parser/grammar if the behavior of ; in the record context is proper)

       {
            name: history_menu
            modifier: none
            keycode: "char_;"
            mode: [emacs, vi_insert, vi_normal]
            event: { send: menu name: history_menu }
        }

One general limitation with some of those special characters is that the ANSI default keyboard protocol will not always carry the modifier info with some of those. What gets transmitted from the terminal is generally really the text. While on a QWERTY keyboard it would correctly show without modifier as found on the layout, with the Russian keyboard it probably won't show the SHIFT-4 as it doesn't show a SHIFT for German QWERTZ (here ; is in the shifted position of ,)

I don't quite follow the example in your motivation.

You can define a binding to ; with the existing config logic as well, the limitation is only imposed by the unquoted string, a ; semicolon will act as a statement separator so it only sees the char_.
One general limitation with some of those special characters is that the ANSI default keyboard protocol will not always carry the modifier info with some of those. What gets transmitted from the terminal is generally really the text. While on a QWERTY keyboard it would correctly show without modifier as found on the layout, with the Russian keyboard it probably won't show the SHIFT-4 as it doesn't show a SHIFT for German QWERTZ (here ; is in the shifted position of ,)

Oh, I didn't know you could assign keys like "char_;". That's definitely cool 😊. On the other hand, I think adding uXXXX won't be much of an inconvenience, and it allows, for example, separate categorization of uppercase and lowercase Latin letters. Although the latter is probably not very useful since switching is done via SHIFT.

And you are right that modifier: none + keycode: "char_;" or modifier: none + keycode: char_u003B doesn't work. I found experimentally that you need to set modifier: shift for this to work 😊

IIRC, I think the issue was less about char_; and more about some special unicode character that aren't on english keyboards, although it is also about char_;. Seems like the discussion for this was on discord somewhere but it was like a double u character now W but char_uu but one character. Maybe it would be better to have that as an example.

Found it: https://discord.com/channels/601130461678272522/614593951969574961/1292426188765265951

{
    name: enter_vi_insert_mode
    modifier: none
    keycode: char_ш
    mode: vi_normal
    event: { *Some magic to change to vi_insert ??* }
}

IIRC, I think the issue was less about char_; and more about some special unicode character that aren't on english keyboards, although it is also about char_;. Seems like the discussion for this was on discord somewhere but it was like a double u character now W but char_uu but one character. Maybe it would be better to have that as an example.

Found it: https://discord.com/channels/601130461678272522/614593951969574961/1292426188765265951

{
    name: enter_vi_insert_mode
    modifier: none
    keycode: char_ш
    mode: vi_normal
    event: { *Some magic to change to vi_insert ??* }
}

Oh, that's a different issue. I have some thoughts about adding a separate variant in EventType, like EventType::Command, and putting something like Command::EnterViInsert there. But I'm not sure yet. Another option would be to have KeybindingsMode store all three: emacs_keybindings, insert_keybindings, normal_keybindings, so that the Nushell mode can be changed on the fly.
If, of course, the Nushell team considers any of these changes acceptable.

I know getting insert mode to work is a different issue but i thought char_ш wouldn't work either, just as a key binding?

Found it: discord.com/channels/601130461678272522/614593951969574961/1292426188765265951

{
    name: enter_vi_insert_mode
    modifier: none
    keycode: char_ш
    mode: vi_normal
    event: { *Some magic to change to vi_insert ??* }
}

Here the problem seems more towards what can be mapped and not the char_ dispatch. We permit a single char (so anything that is one Unicode codepoint, not joined) as this the unit that we can decode via crossterm.
From a readability and usability perspective I personally prefer that this binding is WYSIWYG. If you can generate character in the config with your keyboard you most likely can trigger the key via crossterm. One argument I can see is one might disambiguate via the Unicode id if you meant the U+003B ; semicolon or the confusable Greek question mark U+037E ; (but not sure what the keyboards/terminals do there)
The cyrillic alphabet as found on the keyboard also produces single codepoint chars e.g. й is its own char (2-bytes in UTF-8) and not some joined grapheme by combining и and some grave diacritic mark.

Our vi mode parser itself is not very advanced at the moment so doesn't permit remapping of anything in the state machine for the normal mode key sequences. So if you :noremap your way out of the incompatibilities of vim with non-QWERTY keyboards, we can't provide an easy way out at the moment.

I know getting insert mode to work is a different issue but i thought char_ш wouldn't work either, just as a key binding?

No, just like the key binding char_ш works, there are no problems with that.

No, just like the key binding char_ш works, there are no problems with that.

ok, my mistake. so, this PR is really about char_; alone then. still seems reasonable to me.

Here the problem seems more towards what can be mapped and not the char_ dispatch. We permit a single char (so anything that is one Unicode codepoint, not joined) as this the unit that we can decode via crossterm. From a readability and usability perspective I personally prefer that this binding is WYSIWYG. If you can generate character in the config with your keyboard you most likely can trigger the key via crossterm.

I have to disagree on one point: the current implementation doesn't distinguish between uppercase and lowercase Latin characters, meaning you can't assign different actions to A and a, though this is possible for non-Latin characters. Therefore, WYSIWYG isn't fully achieved for Latin characters 🙂.

Therefore, WYSIWYG isn't fully achieved for Latin characters 🙂.

Yeah that lazy to_ascii_lowercase makes it a bit lax. In the history of crossterm there was a time where the capitalization of the shifted characters was less clearly defined so we probably went with that. But for all the ASCII alphabetical characters at least shift is properly detected (in contrast to the Ctrl versions)

@JustForFun88 it would be good to have some documentation on this change in the upcoming release blog if you have time? here's the current PR that people contribute things like this to nushell/nushell.github.io#1566

@JustForFun88 it would be good to have some documentation on this change in the upcoming release blog if you have time? here's the current PR that people contribute things like this to nushell/nushell.github.io#1566

I think that I can prepare PR tomorrow