Hi It is a good idea to make wscons more like xterm, at least so far as setting TERM to xterm will not cause major problems for most programs.
Hardly anything uses blinking and the lack of it will bother nobody so TBH I wouldn't worry too much about it. Your diff looks good to me, although it would be nice to label the cases with the escape sequence names like most of the existing ones, eg VPA, HPA, SD, SU, CBT. I am not able to test it however. It looks like SD and SU are VT420 sequences, but we should definitely be careful about ever promising to be VT420 because it has a large variety of weird and wonderful stuff, much of it useless. https://invisible-island.net/xterm/ctlseqs/ctlseqs.html and https://vt100.net/ are useful pages here, although you have probably seen them already. On Sat, 31 Dec 2022, 23:37 Crystal Kolipe, <kolip...@exoticsilicon.com> wrote: > The following patch adds five escape sequences to the wscons vt100 > emulation. > > It's one part of a larger set of patches I am working on to make the > console > more like xterm. > > Note: Casual readers of -tech and those not familar with terminfo might > prefer to read my write-up at > https://research.exoticsilicon.com/articles/terminal_emulations > > Why do we want this? > > Currently the console emulates a superset of a subset of vt220 features. > > In other words, it supports most common vt220 sequences and a few > additional > sequences to do things like set colours, (which a real vt220 doesn't > support). > > The problem is that since the terminal emulation has to default to > something > that is universally recognised, it's set by default to vt220, (in > /etc/ttys). > > This means that none of these 'extra' features are available to > curses-based > programs running on the console, unless the user manually fiddles with the > terminal type. > > The terminfo file has long included 'pccon', which claims to support the > OpenBSD console, but this entry has numerous issues such as: > > * Simultaneous use of colour and underline is disabled, even though the > framebuffer console supports it, (presumably because the VGA console does > not). > > * The op entry is hard coded to set black text on a white background > instead > of resetting the terminal to it's default colours. This causes, for > example, > the mutt email client to exit with the terminal inverted, (black text on > a > white background). > > * It doesn't include support for civis or cnorm, (to hide/restore the > cursor), > even though both the framebuffer console and the VGA console support it. > > Even using the vt220 entry as is currently done causes some issues beyond > lack > of colour: > > * F1-F4 are not recognised as they send different sequences to what the > vt220 > entry expects. > > * Also doesn't include civis or cnorm. > > Fixing up the pccon entry is not feasible, as it would take many years for > an > updated version to appear on a sufficient number of systems for it to be > suitable as a default in /etc/ttys. > > The solution: > > If wscons can be made to work adequately with the existing xterm entry in > the > terminfo file, then xterm could eventually become the default terminal > emulation. > > In 2023, the xterm emulation should be almost as universally accepted as > vt220, and allows for many more features such as colour. > > Currently, setting TERM=xterm in the console and starting any curses-based > program will quickly show a lot of breakage. > > Comparing the terminfo entries for vt220 and xterm, the most obvious > functions > that are missing from the vt220 entry and which are not currently > supported by > wscons are: > > Sequence Equivalent to termcap Description > > CSI x T rin scroll back x lines > CSI x S indn scroll forward x lines > CSI x d vpa go to line x > CSI x G hpa go to column x > CSI Z cbt reverse horizontal tab > > (Note: indices are 1-based and not 0-based.) > > These are the five functions implemented by the attached patch. > > Already, just enabling these functions makes a lot of curses programs run > fine > on the console - in colour - with TERM set to xterm. > > This patch is very unintrusive, and it's hard to see how it could break > anything. It also allows for more widespread testing with TERM=xterm to > find > out what works and what doesn't, and any odd corner cases. > > Beyond this, things become slightly more complicated for several reasons: > > 1. Xterm implements some features such as dim text, strikethrough, double > underline, and italics, which wscons doesn't yet support. I have code > to > implement the first three in rasops32, but didn't make that part of this > diff to keep things simple. > > 2. Xterm implements blinking text, which would require a lot of changes to > implement on the framebuffer console. Should blinking text be > represented > in another way, (boxout? overline? drop shadow?) > > 3. To make the F1-F4 keys be recognised by the xterm termcap entry requires > either changing the sequences they send in wsemul_vt100_keys.c, or > changing > the various keymaps in wskbdmap_mfii.c to use KS_KP_F1 - KS_KP_F4 > instead > of KS_f1 - KS_f4. > > These keys currently do NOT work by default anyway, as the vt220 termcap > entry > also requires the same change(!), however it would break pccon, which does > correctly include the sequences that wscons currently generates. A similar > situation exists for F13 - F24, home, and end. > > The keypad +, -, *, and / keys do currently work with vt220, but break > using > the xterm entry, (but only for programs that use them via termcap, > obviously). > > Overall, the potential for breakage with this first patch is very small and > even with the proposed future changes, should only affect people who are > using > a non-default configuration, or programs that rely on the terminfo > description > of the four previously mentioned numeric keypad keys. > > The potential advantages of this current proposed patch as a first step > towards a change to xterm are: > > * No breakage for anybody using the default vt220 terminfo entry, (or > pccons). > * Easy to test the new functionality by setting TERM=xterm. > * The xterm target is very widely supported already and has been for a long > time. > * Eventually xterm could become the default, and curses-based programs will > 'just work'. > > Comments? Feedback? Do other people even care about this? >
