ALT key combo in 8-bit mode

[determin1st]

ALT key combination while terminal is in 8-bit produces 7-bit response

for example, pressing ALT+a key combo in xterm produces C3:A1 in hex, while kitty produces 1B:61

i had a little dive into that C3 thing, here's the code from xterm

		if ((ch < 128) && (screen->eight_bit_meta == ebTrue)) {
		    kd.strbuf[0] |= (char) 0x80;
		    TRACE(("...input shift from %d to %d (%#x to %#x)\n",
			   ch, CharOf(kd.strbuf[0]),
			   ch, CharOf(kd.strbuf[0])));
#if OPT_WIDE_CHARS
		    if (screen->utf8_mode) {
			/*
			 * We could interpret the incoming code as "in the
			 * current locale", but it's simpler to treat it as
			 * a Unicode value to translate to UTF-8.
			 */
			ch = CharOf(kd.strbuf[0]);
			kd.nbytes = 2;
			kd.strbuf[0] = (char) (0xc0 | ((ch >> 6) & 0x3));
			kd.strbuf[1] = (char) (0x80 | (ch & 0x3f));
			TRACE(("...encoded %#x in UTF-8 as %#x,%#x\n",
			       ch, CharOf(kd.strbuf[0]), CharOf(kd.strbuf[1])));
		    }
#endif
		}

i see it is copied from somewhere. one can find it by metaSendsEscape search in input.c. so the algo is related to unicode, which is mandatory today..

so what it does is, it splits the 61 in two parts, the first is

C3 == 0xC0 | (((0x80 + 0x61) >> 6) & 3)
A1 == 0x80 | (0x61 & 0x3F)

which is rather waky transition to me. i dislike both variants equally. the 1B variant will be treated as ESC keypress in the 8-bit parser, which is better than 7-bit parser that is unable to differentiate ESC properly by design. though, suppose this cryptic code can be unrolled to a nice map, im just quickreporting this issue

[kovidgoyal]

In legacy keyboard mode alt+a produces 0x1b a i.e. ESC and a
https://sw.kovidgoyal.net/kitty/keyboard-protocol/#legacy-key-event-encoding

[determin1st]

it is related to 7-bit mode responses

8-bit response to ALT combo is different

this is an incompatibility

[kovidgoyal]

kitty does not support 8-bit controls and never will. They are a bad idea. A bit of googling will tell you why

[determin1st]

They are a good idea. I know that without googling (because im implementing the parser). Ye, i didnt notice that kitty doesnt send 8-bit keys.. still it sends 8-bit response to CPR after switching into 8-bit mode. how do you explain that?

[kovidgoyal]

On Thu, Mar 28, 2024 at 12:19:52AM -0700, determin1st wrote: They are a good idea. I know that without googling (because im implementing the parser).

The world is bigger than your parser.

Ye, i didnt notice that kitty doesnt send 8-bit keys.. still it sends 8-bit response to CPR after switching into 8-bit mode. how do you explain that?

It doesn't. Support for 8-bit controls was dropped in kitty 0.33.0. kitty no longer recognizes them and no longer generates them. IIRC the *only* major terminals left that still accept them are wezterm and libvte based ones out of the box. And xterm if you configure it to do so via the eightbitcontrol resources.

[determin1st]

The world is bigger than your parser.

the world is smaller than my parser. otherwise show me the 8-bit parser or explain in a single sentence why 8-bit parser is better than 7-bit parser (but you said its worse, so i know you never wrote one)

It doesn't. Support for 8-bit controls was dropped in kitty 0.33.0. kitty no longer recognizes them and no longer generates them. IIRC the only major terminals left that still accept them are wezterm and libvte based ones out of the box. And xterm if you configure it to do so via the eightbitcontrol resources.

it is. i have the latest Debian 12 apt install kitty, so it produces 8-bit responses. if you never wanted 8-bits, you wouldnt put them in there. the version is 0.26.5. apt install xterm supports 8-bits without configuring.

[kovidgoyal]

On Thu, Mar 28, 2024 at 12:52:38AM -0700, determin1st wrote: > The world is bigger than your parser. the world is smaller than my parser. otherwise show me the 8-bit parser or explain in a single sentence why 8-bit parser is better than 7-bit parser (but you said its worse, so i know you never wrote one)

ROFL. Sure. Good luck with your parser.