Issue with non-default keyboard layout not being interpreted correctly

[soenkeliebau]

lnav version
master (0.13.0)

Describe the bug
I am using the Neo2 keyboard layout, which has different layers for special characters, plus all letters remapped to other keys as well.

The weird behavior that I observed is related to the ] character, which can be found on layer three as seen in this screenshot:

This is on the same physical key as the letter c on layer 1:

When I try to press 'Ctrl-]' in lnav to for example put the cursor in the pretty print box , it seems to me like lnav interprets this as Ctrl-C and simply quits, instead of correctly recognizing the special character instead of the c.

This still works in 0.12.3, but appears broken in the master branch. I am happy to do a git bisect and try to isolate a commit that may have influenced this, but I wanted to open an issue first, maybe you know otoyh that you changed something around keyboard handling recently ..

To Reproduce
Steps to reproduce the behavior:
switch keyboard layout to "de neo", open lnav,hit p on a logline to show pretty view, hit "Ctrl-Mod 3-c" (c being the neo key, r would the the character printed on the physical key).

Expected result: cursor jumps into pretty view.
Actual result: lnav quits

[tstack]

I think it can depend on the terminal, what are you using?

[soenkeliebau]

Mostly ghostty at the moment, not sure if I also tested it in alacritty (with zellij which may change behavior)..

I'm like 90% sure that I tested both versions in the same terminal though.. I'll recheck, just to be totally sure.

[tstack]

In lnav v0.12.4, I switched from ncurses to notcurses, which uses the kitty keyboard protocol if it's available. I think both ghostty and alacritty support that, which is probably why it used to work but is broken now.

Also, if you're playing with the master branch, are you having any problems with the new prompt implementation?

[soenkeliebau]

I can confirm that 0.12.4 is the version that breaks it - tested on both ghostty and alacritty.

Brief googling didn't turn up a way to suppress using this in either of those terminals. From my understanding the application i.e. lnav (or notcurses probably) requests this mode and the terminal then switches to it?

Regarding the new prompt implementation ... maybe :)
I did observe weirdness where upon startup some apparently random characters were entered and an input mask was open on the bottom of th screen ... I've so far ignored that due to being more interested in the keys issue.
Is there anything specific you have in mind that I should look out for?

[soenkeliebau]

There is a lot of prior art about the kitty protocol, especially in relation to modifiers and how they are encoded..
I don't understand most of it :)
ghostty-org/ghostty#4965
kovidgoyal/kitty#6913
alacritty/alacritty#7435

What I can definitely confirm is that running kitten show_key -m kitty terminates on the same key sequence - so this is definitely kitty keyboard protocol related..

I guess the easiest solution is for me to remap this in lnav, if that is possible, haven't looked in depth yet.

[tstack]

Hmm, I installed this keyboard layout on macOS and I can't replicate it working under v0.12.3 .

Opening the system's Keyboard Viewer seems to show that pressing the "option" key switches the "R" key to be bracket. However, when I press the CTRL key, the "R" key switches back to "c". Here's a gif of it:

I have tried pressing a bunch of keys, but I can't figure out how to make it work...

[tstack]

When I try to press 'Ctrl-]' in lnav to for example put the cursor in the pretty print box

For this specific case, if you update your master branch, you can use the following config to bind a key (F6 in the example) to move the focus to the overlay:

:config /ui/keymap-defs/default/f6/command ;UPDATE lnav_views SET options = json_set(options, '$.overlay-focused-line', 0) where name = 'log'

(The overlay-focused-line was available in previous versions, but there was a glitch that prevented it from working in some cases.)

You can use Escape to cancel a prompt. But, I don't think there's an alternative way to cancel a running SQL query, that still only works with CTRL + ].

[soenkeliebau]

I can't speak for MacOS, sorry. But there seems to be a difference specifically in behavior with modifiers and how they are communicated between MacOS and Linux, if I understand this correctly, it may be to do with that... but again, I'm almost entirely guessing here :)

I played around with kitten a bit, and it really looks like the Caps-Lock information is simply lost in the kitty keyboard protocol ..

I ran kitty show-key -m kitty and got the following:

To me it really looks, like there is nothing to do here, as the information is simply not available..

I'll do some more reading and if applicable open an issue in the kitty repo, but wouldn't expect anything to change as a result of that quite honestly.

For me personally, I'll just remap this.

Also, I have a keyboard around that I have just been too lazy to switch to, which runs qmk .. I'll be interested to see if that works. I think it should, because the terminal will in all probability never see the "C" key being pressed, as all the Modifier etc handling is done in the keyboards firmware then..

[tstack]

The terminal is handling the CTRL+C, though. It sends a SIGINT to lnav. I don’t think lnav checks for it. Lnav logs the input events it’s working with, you could turn on debug logging and check there.

[tstack]

Regarding the new prompt implementation ... maybe :)
I did observe weirdness where upon startup some apparently random characters were entered and an input mask was open on the bottom of th screen ... I've so far ignored that due to being more interested in the keys issue.

On startup, the notcurses code sends a bunch of escape sequences to the terminal and expects some responses. Sometimes, the responses are not recognized and get misinterpreted as input from the user. I thought I fixed most of those issues, but I guess it is still happening in some cases.

Is there anything specific you have in mind that I should look out for?

I was thinking more about editing (single and multiple line), tab-completion, and such.

[soenkeliebau]

The terminal is handling the CTRL+C, though. It sends a SIGINT to lnav. I don’t think lnav checks for it. Lnav logs the input events it’s working with, you could turn on debug logging and check there.

I did some further reading, won't pretend that I really understand all this, but I did notice, that caps-lock is correctly sent as modifier when I switch to the normal german layout.

I think the issue is, that the kitty protocol dictates that the basekey needs to be sent, with modifiers .. basekey in this case is E for the normal layout L for neo (I'll only use 'L' going forward) .. but caps lock is apparently not treated as a modifier for neo .. as indicated when I simply type a [ (Caps-Lock + L )

This doesn't send the keycode for L with a modifier set, but instead translates to [.
This translation doesn't seem to happen when adding Ctrl to the mix, so this looks like Ctrl-L instead of Ctrl-[

I think its something to do with the difference between "key exists on the default us keyboard layout" and "key doesn't exist there"... then again, isn't [ a hardware key on US keyboard? That kinda counters my theory..

I found a few issues that sound relevant and a blog post, just dumping them here if someone ever investigates the same thing - I focussed on the kitty repo here, should have probably been the ghostty repo, since kitty only defines the protocol

kovidgoyal/kitty#2000
kovidgoyal/kitty#1990
https://jakeroid.com/blog/kitty-shortcuts-work-only-with-latin-characters-how-to-fix

Also... one of these seems to have fixed it in kitty..
Kitty correctly interprets Ctrl-[ :

Should have probably tested this much earlier :)
Jumping to the pretty box in lnav works in kitty as well.

I'll open an issue in ghostty (and maybe Alacritty as well) and refer to the tickets mentioned above in the hope that someone who actually knows how this all works can figure out what the proper fix needs to be.

[soenkeliebau]

Regarding startup behavior and escape sequences, both ghostty and kitty seem to be fine, but in Alacritty it looks like this after startup, which may or may not be what you were referring to?