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