From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 24093 invoked from network); 7 Oct 2022 18:15:07 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 7 Oct 2022 18:15:07 -0000
Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Fri Oct  7 14:14:13 -0400 2022
Received: from abbatoir (pool-108-27-53-161.nycmny.fios.verizon.net [108.27.53.161])
	by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 2674811e (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO)
	for <9front@9front.org>;
	Fri, 7 Oct 2022 11:14:12 -0700 (PDT)
Message-ID: <500E574000B68288364FAD993DCA8DAB@eigenstate.org>
To: 9front@9front.org
Date: Fri, 07 Oct 2022 14:14:11 -0400
From: ori@eigenstate.org
In-Reply-To: <1132EA054DF091104D293E57741F6906@mforney.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: grid base-oriented plugin just-in-time-based optimizer 
Subject: Re: [9front] [PATCH] vt: fix home/end sequences in xterm mode
Reply-To: 9front@9front.org
Precedence: bulk

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 */