Numeric keyboard is printing "j" when "enter" was pressed in pickers

[jcbritobr]

Summary

The numeric keyboard is printing the "j" character when "enter" key was pressed.

Reproduction Steps

1 - Open helix
2 - press space + s or space + f to get a file or symbol picker
3 - select a symbol or file and press "enter" in numeric keyboard

expected behavior:
open the file or select the symbol and return to edition

happens:
the key "j" is printed instead.

Helix log

No response

Platform

Linux

Terminal Emulator

alacritty

Helix Version

23.05

[Snoupix]

After a quick try, I don't have this issue, have you remapped this specific key on a keyboard software, it's firmware or in your alacritty settings ?

[jcbritobr]

After a quick try, I don't have this issue, have you remapped this specific key on a keyboard software, it's firmware or in your alacritty settings ?

Hello, did more tests and I see this is happening with alacritty. I had installed kitty and had not got this issue. Happens only in Alacritty with no tweak. As it was installed.

[Snoupix]

Hi, alright, it seems to be an Alacritty (config) "issue" then :)

[jcbritobr]

Hi, alright, it seems to be an Alacritty (config) "issue" then :)

dont know if is config, because I dont changed anything on alacritty. Maybe a default configuration.

[dilr]

I also had this issue when running in MacOS with Terminal.app, but only when running helix through the lldb debugger. I was able to actually input <Enter> by pressing <C-v> and then <Enter>. I'll take a closer look when I get the time. In the meantime, I think the <C-v> <Enter> workaround should make helix usable.

[dilr]

Further debugging finds that Crossterm sends a <Enter> event when in insert mode (and so insert mode works properly), but sends a <C-j> event in prompt mode. It makes sense to send <C-j> since that is the ascii code for enter, but evidently crossterm gets a more accurate event somehow when doing insert mode. My guess is that this has something to do with differences in crossterm settings which are used when rendering in insert mode vs prompt mode. I'll keep digging, but if someone who knows the rendering code better could chime in, that would be helpful.

[dilr]

@jcbritobr, could you post every program that runs between your terminal emulator and helix? For instance, for me the issue happens with Terminal.app -> zsh -> lldb -> hx. I highly doubt the issue is actually alacritty, but if you are running helix through ssh for example, that could possibly cause the issue. It is also possible that you are using a shell which is pulling some sort of funny behavior.

At least in my case, the issue ended up being that lldb sets up an extra inner psuedo terminal between helix and the terminal emulator. The original psuedo terminal (which helix can't modify) had ICRNL set in its itermos structure. This causes helix to receive newlines when enter is pressed rather than the carriage returns it expected based off the settings it made to the inner pusedo terminal. I can imagine ssh making this mistake as it needs to set up a separate psuedo terminal on the remote host in order to function.

The reason kitty works when alacrity doesn't is probably because kitty has its comprehensive keyboard handling mode, which would completely bypass the effects of ICRNL. I would expect the issue to still occur if you used some other non-kitty terminal emulator.

[jcbritobr]

Hello, good morning. The issue for me only happens using alacritty vanilla. No plugins or configs. Just start alacritty, use helix from it.
I'm using kitty now and I don't have this issue in it.

[pascalkuthe]

A ton of people are using alacrity with helix and never heard of such issues. Which alacrity version did you use? And are you using something lime termux?

[jcbritobr]

fedora ratatuisamp]$ hx --version
helix 23.05 (7f5940b)

Remember this happens in a numeric keyboard. Its clearly a bug

[dilr]

Does this only happen when you use the numeric keyboard?

[gabydd]

Looks like the numeric keyboard enter generates a different keycode then enter is: zyedidia/micro#2774 which is interpreted as C-j, and looking at: crossterm-rs/crossterm#371 I am guessing C-j used to be interpreted as enter but that was changed. I think the best solution right now is too probably remap the keycode or key like suggested in the micro issue

Edit the pr to fix the crossterm issue I mentioned was: crossterm-rs/crossterm#373

[dilr]

Thanks for the zyedidia issue. The info there could be quite helpful. If it is just keypad enter which causes the issue, then the bug is definitely on the terminal emulator or desktop side, and doesn't extend to the shell or whatnot.

I suspected that numpad enter getting translated to newline by alacritty might the case. I have tried to trace how Alacritty translates keypresses into ascii characters to feed to the pty. I don't have a linux system or a numpad, so I can't test, but the gist is that Alacritty translates keypresses to ascii by asking the xkbcommon library for the utf8 equivalent of a keypress. The xkbcommon library translates both standard enter and numpad enter to carriage return. Thus alacritty shouldn't be doing anything wrong here. It is possible that there is a problem with desktop configuration, but the issue @gabydd just provided would suggest that is not the case unless the terminal emulator that the issue opener is using does something different than alacritty.

The details are provided below. Its probably safe to skip them unless you have your own suspicions though.

The point at which Alacritty translates the keypress event to text is here. This simply asks winit for the key in utf8 form. Winit defines the appropriate trait here and implements it for KeyEvents on linux here. The implementation is just reading a cached string, which is created here using the function here, which should just pass through to this function since we aren't doing any compose key stuff. That last function is in the XkbCommon library here, which calls this function, which calls this function. This function finally does the translation to a codepoint here. It masks the keysymb by 0x7F. Looking here, we find that the keysymb for XKB_KEY_Return is 0xff0d, and for XKB_KEY_KP_Enter is 0xff8d. Performing the masking for both, we find that the result is 0x0d, which is carriage return.