Some control key combos are eaten

[humblehacker]

In the helix editor, I have some functions mapped to ctrl+. and ctrl+,. These mapped keys work in iTerm, but not in SwiftTerm (nor in macOS Terminal). Is it possible to get these keys to work in SwiftTerm?

[migueldeicaza]

I have no clue what those do, and in iTerm I do not see those do anything.

So you might need to provide additional information.

[humblehacker]

Ok, I dug into this a little deeper. Helix uses the library crossterm to handle keyboard input, among other things. Crossterm includes example applications to test this input. When I compile and run one of the examples in iTerm and type control + period, the event is output:

Event: Key(KeyEvent { code: Char('.'), 
modifiers: KeyModifiers(CONTROL), kind: Press, state: KeyEventState(0x0) })

When I run the same program in SwiftTerm (via MacTerminal sample app) and attempt the same keystrokes, nothing is output.

Here is the test program, if you're interested in trying it yourself: event-read.zip. It comes from compiling this example

I haven't yet looked at what crossterm is doing, but I have been comparing how iTerm and SwiftTerm handle input -- so far without luck. Since you have more experience with terminal input than I do @migueldeicaza, I was hoping you could point me in the right direction.

[migueldeicaza]

Thanks for the in-depth discussion and the test case, I will review it.

My version of iTerm merely outputs . or , if I press the control key, it makes me wonder if this is a non-standard encoding.

The story is that Control-A through Control-z were mapped to values ascii 1 to ascii 26, and the patch you provided merely does a pass through with the . and , keys (the patch also means that any other keys will get passed through, which should not).

I am not sure how they detect the control key being pressed, so I suspect this is sending an extended sequence that details that.

Thanks for sharing the example and the link to the program, I will investigate what is going on.

[humblehacker]

Thanks @migueldeicaza. I don't know how far you've gotten already, but I did discover the sequence that results in the correct output from event-read. I've updated my PR #323. I don't expect this is the final solution, but I hope it helps to move this along. I would like to understand where this magic sequence comes from.

[humblehacker]

I think I may have found the origin in iTerm: https://github.com/gnachman/iTerm2/blob/a09c3c5569c2d20819e23f5f9dcfefffc445baea/sources/iTermTermkeyKeyMapper.m#L98-L105

Which leads to:

• CSI u (iterm2.com)
• Fix Keyboard Input on Terminals - Please

Interesting rabbit hole. I think I'll leave it here. Looking forward to your solution.

[migueldeicaza]

Thank you for the background information!

This explains a lot, and I had filed earlier a bug about tracking this extended new input format:

#180

There is a useful link there to the standard as it stands now, will look into doing the complete implementation, which is a little more elaborate. These new sequences would be sent when client apps opt into the extended input, they would not be sent normally:

https://sw.kovidgoyal.net/kitty/keyboard-protocol/

[migueldeicaza]

This branch shows the basic setup for the extended input, I still need to wire up all the function keys and audit every character, but this is roughly how it goes, and does handle the scenarios that started the discussion:

main...extended-keyinput

[humblehacker]

Thanks for jumping on this so quickly! Nice to see the progress.