On Wed, Jul 09, 2025 at 03:40:39PM -0300, Crystal Kolipe wrote:
...
> Until I started sending these wscons patches at the end of 2022, wscons was
> basically superset of a subset of vt220 emulation.  In fact, it's always been
> quite far removed from a real vt220.
> 
> _None_ of the terminfo entries worked correctly on the console.
> 
> vt220 was and is broken, as the F1 - F4 keys are incorrectly mapped amongst
> other things, and there is no support for colour because real vt220s don't do
> colour.

It was never correct.
 
> pccon was broken in various ways.  The ncv#2 entry prevents use of colour and
> underline at the same time, which might have made sense for VGA text mode,
> but we're in 2025 now and things have moved on.  The op parameter resets to
> black text on white, which is unexpected for users who didn't grow up with
> the sparc console.  Other control sequences are also missing.

pccon is the place to make fixes, though, since it applies to OpenBSD.
Others have noticed that:

https://lists.gnu.org/archive/html/bug-ncurses/2015-11/msg00010.html

> So it was impossible for software that parsed termcap/terminfo to fully use
> the functionality that was present.

...terminfo/termcap are, like other software, not carved in stone.
 
> As Stuart points out, a lot of software just assumes that it's running on an
> ECMA-48 capable display.  And ironically, that software just worked.  It also
> almost certainly works in a real xterm and on the linux framebuffer console,
> because these control sequences are supported on virtually all vaguely modern
> terminal emulators.
> 
> At this point, the obvious, (to me), terminfo entry to target was xterm,
> because why not?  Any recent OS that has a terminfo file at all is going to
> have a good quality terminfo entry for xterm, because it's what people use
> and they expect it to work.
> 
> So our compatibilty with xterm in the most part really means compatibilty
> with the xterm terminfo entry.
> 
> Now bearing in mind that xterm is itself basically a superset of vt220, this
> doesn't create much of a problem in terms of backwards compatibility.
> 
> Almost anything that worked on a vt220 should work just fine on xterm, and by

reading the manpage would help.

https://invisible-island.net/xterm/manpage/xterm.html

xterm's defaulted to vt420 for more than ten years.

https://invisible-island.net/xterm/xterm.log.html#xterm_280

> extension, 99% of those can work on a minimal implementation of xterm control

probably not, unless you're assuming that the 99% just copy/paste from each
other :-)

> But at the moment we are only part of the way there.  I am fairly confident
> already that TERM=xterm will not break many user's systems.  But maybe there
> are a few xterm control sequences that we don't implement yet that are indeed
> in common use.  We need to find out.

Actually, reading tmux's source also would be helpful.
You might notice that it's using features that aren't in a vt220.
 
...all of the comments which I'm reading indicate that you'll produce
something which will be reported to me as bugs.

Start by reading the documentation, then the source code.
Ignore forum chatter.

have a nice day.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net