Rewriting alt-ARROW STDIN to hard-coded 1;5?

[imsnif]

Hey, I didn't use the issue template because I have a specific question about xterm.js's behavior. I hope it's alright.

I'm working on integrating xterm.js with zellij and I'm encountering an issue stemming from these lines:

xterm.js/src/common/input/Keyboard.ts

Line 162 in 41e8ae3

result.key = C0.ESC + '[1;5A';

I'm happy to be corrected on this one, but as far as I know, in both linux and mac the standard ANSI notation for these sequences is <CSI>1;3B for alt + down-arrow, <CSI>1;3A for up-arrow, etc. I'm a little puzzled by why these are sent as <CSI>1;5B, etc.

This is obviously also causing Zellij not to properly interpret these keys. Right now I'm getting around this with term.AttachCustomKeyEventHandler - which is alright for my use-case, but I'm wondering if there's an underlying reason here that I'm missing and perhaps should account for.

Thanks!

[Tyriar]

It's explained right above that:

xterm.js/src/common/input/Keyboard.ts

Lines 157 to 163 in 41e8ae3

	result.key = C0.ESC + '[1;' + (modifiers + 1) + 'A';
	// HACK: Make Alt + up-arrow behave like Ctrl + up-arrow
	// http://unix.stackexchange.com/a/108106
	// macOS uses different escape sequences than linux
	if (!isMac && result.key === C0.ESC + '[1;3A') {
	result.key = C0.ESC + '[1;5A';
	}

This is one of the non-standard things xterm.js does that's a little risky to change at this point. If you want the standard behavior attachCustomKeyEventHandler is indeed the right thing to do

[imsnif]

Thanks for the quick response. For the record, the linked comment doesn't actually (to my reading) explain why one should send 1;5 for both Alt and Ctrl (to my knowledge this is only used for Ctrl, with Alt it should be 1;3). My guess is that this is worked around in some other place because otherwise I'm a little confused by how Alt arrow bindings would work at all.

In any case, I'm happy to work around this with attachCustomKeyEventHandler, and I can definitely understand not wanting to change anything that "just works". Thanks again and all the best.

[Tyriar]

I didn't check the history, but I probably added it a long time ago when I didn't know as much about terminal input to make things more consistent. If I was to do this sort of thing now I'd do the base behavior in xterm.js and make custom keybinding inside VS Code for the non-standard behavior.

[jerch]

Yes thats "evolved" code, that happens to work for so long (although it might be slightly off for some edge cases).

All in all Keyboard.ts is prolly the ugliest piece of code in xterm.js - that mostly got shaped by hundreds of forth and and back changes against different browsers and their idea of proper keypress event propagation. That being said, it full of pitfalls that cannot be changed easily, as things like IMEs depend on it. Imho we tried twice or 3 times to untangle it - well we were not very successful with that 😅

[imsnif]

Haha, I know what you mean! The only software without hacks and ugly code is software that is not (widely) used.

I only brought this up because I wanted to make sure I'm not bypassing something important. Thanks for the work you all do!