[9front] [PATCH] vt: fix home/end sequences in xterm mode

[9front] [PATCH] vt: fix home/end sequences in xterm mode

[Michael Forney]

According to the ncurses terminfo database, we have

$ for k in khome kend; do printf '%s:\t' $k; TERM=xterm tput $k | od -An -tc; done
khome:	033   O   H
kend:	033   O   F
$

This differs from vt220fk, so add a new xtermfk table with the proper
sequences.
---
I also noticed that the vt220 definition in ncurses terminfo does not
have khome/kend entries, and instead maps the sequences \033[1~ and
\033[4~ to kfnd (key_find) and kslt (key_select), so home/end don't
work with -2 either. However, there is a "vt220-old" definition that
maps them to the same sequences as in the vt220fk table. I'm not a
terminal expert so I don't know which is correct, but just thought I'd
mention it in case someone knows.

diff 7bb34f7d22d90f59eaa3778398ada0b66b0f7b86 e919f465e965129ef3b14003bff5a9c54dcbe8e7
--- a/sys/src/cmd/vt/cons.h
+++ b/sys/src/cmd/vt/cons.h
@@ -39,7 +39,7 @@
 	char	*sequence;
 };
 extern struct funckey *fk, *appfk;
-extern struct funckey ansifk[], ansiappfk[], vt220fk[];
+extern struct funckey ansifk[], ansiappfk[], vt220fk[], xtermfk[];
 
 extern int	x, y, xmax, ymax, olines;
 extern int	peekc, attribute;
--- a/sys/src/cmd/vt/main.c
+++ b/sys/src/cmd/vt/main.c
@@ -286,7 +286,7 @@
 			sysfatal("could not create log file: %s: %r", p);
 		break;
 	case 'x':
-		fk = vt220fk;
+		fk = xtermfk;
 		term = "xterm";
 		break;
 	case 'r':
--- a/sys/src/cmd/vt/vt.c
+++ b/sys/src/cmd/vt/vt.c
@@ -91,6 +91,35 @@
 	{ 0 },
 };
 
+struct funckey xtermfk[] = {
+	{ "insert",		"\033[2~", },
+	{ "delete",		"\033[3~", },
+	{ "home",		"\033OH", },
+	{ "end",		"\033OF", },
+	{ "page up",		"\033[5~", },
+	{ "page down",		"\033[6~", },
+
+	{ "up key",		"\033[A", },
+	{ "down key",		"\033[B", },
+	{ "left key",		"\033[D", },
+	{ "right key",		"\033[C", },
+
+	{ "F1",			"\033OP", },
+	{ "F2",			"\033OQ", },
+	{ "F3",			"\033OR", },
+	{ "F4",			"\033OS", },
+	{ "F5",			"\033[15~", },
+	{ "F6",			"\033[17~", },
+	{ "F7",			"\033[18~", },
+	{ "F8",			"\033[19~", },
+	{ "F9",			"\033[20~", },
+	{ "F10",		"\033[21~", },
+	{ "F11",		"\033[23~", },
+	{ "F12",		"\033[24~", },
+
+	{ 0 },
+};
+
 char gmap[256] = {
 	['_']	' ',	/* blank */
 	['\\']	'*',	/* diamond */

Re: [9front] [PATCH] vt: fix home/end sequences in xterm mode

[ori]

Quoth Michael Forney <mforney@mforney.org>:
> 
> According to the ncurses terminfo database, we have
> 
> $ for k in khome kend; do printf '%s:\t' $k; TERM=xterm tput $k | od -An -tc; done
> khome:	033   O   H
> kend:	033   O   F
> $
> 
> This differs from vt220fk, so add a new xtermfk table with the proper
> sequences.

Looks good to me.
> ---
> I also noticed that the vt220 definition in ncurses terminfo does not
> have khome/kend entries, and instead maps the sequences \033[1~ and
> \033[4~ to kfnd (key_find) and kslt (key_select), so home/end don't
> work with -2 either. However, there is a "vt220-old" definition that
> maps them to the same sequences as in the vt220fk table. I'm not a
> terminal expert so I don't know which is correct, but just thought I'd
> mention it in case someone knows.

at a guess, our vt220 emulation was written against vt220-old, and we
never noticed that terminfo changed. We have 2 options: We can update
our code to match vt220 terminfo, or we can set TERM=vt220-old. Both
will work (and having home/end keys seems nice).

k0ga is our resident terminfo expert, though, and probably has a better
idea of what to do.

Also, on a related note -- an idea floated was to make vt compatible with
st instead of xterm, either via lifting their rendering code and porting
it, or via incremental changes. This would hopefully fix a bunch of quirks
and rendering issues we end up running into.

> 
> diff 7bb34f7d22d90f59eaa3778398ada0b66b0f7b86 e919f465e965129ef3b14003bff5a9c54dcbe8e7
> --- a/sys/src/cmd/vt/cons.h
> +++ b/sys/src/cmd/vt/cons.h
> @@ -39,7 +39,7 @@
>  	char	*sequence;
>  };
>  extern struct funckey *fk, *appfk;
> -extern struct funckey ansifk[], ansiappfk[], vt220fk[];
> +extern struct funckey ansifk[], ansiappfk[], vt220fk[], xtermfk[];
>  
>  extern int	x, y, xmax, ymax, olines;
>  extern int	peekc, attribute;
> --- a/sys/src/cmd/vt/main.c
> +++ b/sys/src/cmd/vt/main.c
> @@ -286,7 +286,7 @@
>  			sysfatal("could not create log file: %s: %r", p);
>  		break;
>  	case 'x':
> -		fk = vt220fk;
> +		fk = xtermfk;
>  		term = "xterm";
>  		break;
>  	case 'r':
> --- a/sys/src/cmd/vt/vt.c
> +++ b/sys/src/cmd/vt/vt.c
> @@ -91,6 +91,35 @@
>  	{ 0 },
>  };
>  
> +struct funckey xtermfk[] = {
> +	{ "insert",		"\033[2~", },
> +	{ "delete",		"\033[3~", },
> +	{ "home",		"\033OH", },
> +	{ "end",		"\033OF", },
> +	{ "page up",		"\033[5~", },
> +	{ "page down",		"\033[6~", },
> +
> +	{ "up key",		"\033[A", },
> +	{ "down key",		"\033[B", },
> +	{ "left key",		"\033[D", },
> +	{ "right key",		"\033[C", },
> +
> +	{ "F1",			"\033OP", },
> +	{ "F2",			"\033OQ", },
> +	{ "F3",			"\033OR", },
> +	{ "F4",			"\033OS", },
> +	{ "F5",			"\033[15~", },
> +	{ "F6",			"\033[17~", },
> +	{ "F7",			"\033[18~", },
> +	{ "F8",			"\033[19~", },
> +	{ "F9",			"\033[20~", },
> +	{ "F10",		"\033[21~", },
> +	{ "F11",		"\033[23~", },
> +	{ "F12",		"\033[24~", },
> +
> +	{ 0 },
> +};
> +
>  char gmap[256] = {
>  	['_']	' ',	/* blank */
>  	['\\']	'*',	/* diamond */

Re: [9front] [PATCH] vt: fix home/end sequences in xterm mode

[hiro]

> Also, on a related note -- an idea floated was to make vt compatible with
> st instead of xterm, either via lifting their rendering code and porting
> it, or via incremental changes. This would hopefully fix a bunch of quirks
> and rendering issues we end up running into.

i think vt isn't based on xterm.
anyway, it was also demonstrated that some "bugs" people claimed to
have found that made them prefer st (and it's slightly different
bugs), came from using weird terminfo, too.

Re: [9front] [PATCH] vt: fix home/end sequences in xterm mode

[ori]

Quoth hiro <23hiro@gmail.com>:
> i think vt isn't based on xterm.

and that's the problem; vt has its set of bugs,
and xterm has its quirks that we don't emulate
quite right.

vttest fails pretty quickly when you try on vt.

https://invisible-island.net/vttest/

Re: [9front] [PATCH] vt: fix home/end sequences in xterm mode

[hiro]

On 10/7/22, ori@eigenstate.org <ori@eigenstate.org> wrote:
> Quoth hiro <23hiro@gmail.com>:
>> i think vt isn't based on xterm.
>
> and that's the problem; vt has its set of bugs,

and xterm has it's own set of bugs that are better not emulated.

> and xterm has its quirks that we don't emulate
> quite right.

why do we need to care so much about xterm's quirks? can't we try to
emulate a real terminal that lacks xterm's quirks? like a vt100 or
vt220?

what kind of programs are you running that needs xterm's quirks?

> vttest fails pretty quickly when you try on vt.

i was not aware of vttest. Is it more authoritative than the bugs
found in xterm, vt, rxvt?
when you tried this software did you set TERM to vt100? to vt220?

Re: [9front] [PATCH] vt: fix home/end sequences in xterm mode

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

hiro writes:

> why do we need to care so much about xterm's quirks? can't we try to
> emulate a real terminal that lacks xterm's quirks? like a vt100 or
> vt220?

Amen.  One of the reasons I prefer to emulate a VTxxx is that the
Linux kiddies have a propensity, when they see 'xterm', to take
license to turn on every form of bling they can get their fingers
into, turning your terminal window into a Christmas tree.  Telling
the system you're on a vtxxx immunizes you from such nonsense.

--lyndon

Re: [9front] [PATCH] vt: fix home/end sequences in xterm mode

[Michael Forney]

ori@eigenstate.org wrote:
> at a guess, our vt220 emulation was written against vt220-old, and we
> never noticed that terminfo changed. We have 2 options: We can update
> our code to match vt220 terminfo, or we can set TERM=vt220-old. Both
> will work (and having home/end keys seems nice).

FWIW, this change happened in ncurses 5.1 from 2000, which predated
the addition of home/end in vt by 17 years.

I was informed off-list that the VT220 keyboard (LK201) has no
home/end keys. Seems to me that the terminfo is correct and they
should be removed from vt220fk.

https://deskthority.net/wiki/images/0/0d/LK201_top.jpg