* [9front] [PATCH] vt: fix home/end sequences in xterm mode @ 2022-10-04 17:34 Michael Forney 2022-10-07 18:14 ` ori 0 siblings, 1 reply; 7+ messages in thread From: Michael Forney @ 2022-10-04 17:34 UTC (permalink / raw) To: 9front 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 */ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] [PATCH] vt: fix home/end sequences in xterm mode 2022-10-04 17:34 [9front] [PATCH] vt: fix home/end sequences in xterm mode Michael Forney @ 2022-10-07 18:14 ` ori 2022-10-07 18:36 ` hiro 2022-10-07 23:12 ` Michael Forney 0 siblings, 2 replies; 7+ messages in thread From: ori @ 2022-10-07 18:14 UTC (permalink / raw) To: 9front 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 */ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] [PATCH] vt: fix home/end sequences in xterm mode 2022-10-07 18:14 ` ori @ 2022-10-07 18:36 ` hiro 2022-10-07 18:49 ` ori 2022-10-07 23:12 ` Michael Forney 1 sibling, 1 reply; 7+ messages in thread From: hiro @ 2022-10-07 18:36 UTC (permalink / raw) To: 9front > 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] [PATCH] vt: fix home/end sequences in xterm mode 2022-10-07 18:36 ` hiro @ 2022-10-07 18:49 ` ori 2022-10-07 21:11 ` hiro 0 siblings, 1 reply; 7+ messages in thread From: ori @ 2022-10-07 18:49 UTC (permalink / raw) To: 9front 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] [PATCH] vt: fix home/end sequences in xterm mode 2022-10-07 18:49 ` ori @ 2022-10-07 21:11 ` hiro 2022-10-07 21:56 ` Lyndon Nerenberg (VE7TFX/VE6BBM) 0 siblings, 1 reply; 7+ messages in thread From: hiro @ 2022-10-07 21:11 UTC (permalink / raw) To: 9front 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] [PATCH] vt: fix home/end sequences in xterm mode 2022-10-07 21:11 ` hiro @ 2022-10-07 21:56 ` Lyndon Nerenberg (VE7TFX/VE6BBM) 0 siblings, 0 replies; 7+ messages in thread From: Lyndon Nerenberg (VE7TFX/VE6BBM) @ 2022-10-07 21:56 UTC (permalink / raw) To: 9front, hiro 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] [PATCH] vt: fix home/end sequences in xterm mode 2022-10-07 18:14 ` ori 2022-10-07 18:36 ` hiro @ 2022-10-07 23:12 ` Michael Forney 1 sibling, 0 replies; 7+ messages in thread From: Michael Forney @ 2022-10-07 23:12 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-10-07 23:13 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-10-04 17:34 [9front] [PATCH] vt: fix home/end sequences in xterm mode Michael Forney 2022-10-07 18:14 ` ori 2022-10-07 18:36 ` hiro 2022-10-07 18:49 ` ori 2022-10-07 21:11 ` hiro 2022-10-07 21:56 ` Lyndon Nerenberg (VE7TFX/VE6BBM) 2022-10-07 23:12 ` Michael Forney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).