On Wed, Jul 09, 2025 at 03:45:15PM -0400, Thomas Dickey wrote:
> 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.

Agreed.

> > 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.

See below.

> 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.

Except that they effectively are, in the large deployed base of older systems
that are in use, for which terminfo updates are not going to be readily
applied.  We want those systems, (which likely do have a solid xterm terminfo
entry), to work when accessed from a current OpenBSD machine.

> > 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.

How does that invalidate my comment that xterm is basically a superset of vt220?

We're not interested in vt420 compatibility, because we never claimed wscons to
be emulating a vt420.  We did claim that it was emulating a vt220, (which was
not an accurate claim).

> 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 :-)

The only way to know, or at least have a reasonable notion of the situation, is
to test it.  Otherwise it's all just 'maybe' and 'probably, (not)'.  On the
testing front, as far as I know, at least some OpenBSD users are setting
TERM=xterm, and where are the complaints?

Is it actually working mostly correctly?
Or are people not testing?
Or are people testing, finding that it doesn't work, and not reporting the issue?

> > 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.

If tmux is using features that are _not_ in a vt220, and we remove code that
implements some vt220 features, how will that break tmux as a result?

> ...all of the comments which I'm reading indicate that you'll produce
> something which will be reported to me as bugs.

Why would users report bugs in wscons to you?  Because it's claiming to
emulate xterm?  So are DEC receiving bug reports about our unfaithful vt220
emulation?  Because we claim that wscons emulates a vt220, but it doesn't?

> Start by reading the documentation, then the source code.

What documentation, and what source code?

The desire here was to make wscons implement the functionality described in
the xterm terminfo entry.  Nothing more, nothing less (*).

(*) I have written other console patches, but those are nothing to do with
    this notion of improving wscons compatibilty with the xterm terminfo
    entry.

I don't see any reason why I would want to study the xterm source code.  I
write my own code, complying with whatever official or de-fato standards it
needs to.

I also have no particular interest in reading the tmux source.  If tmux is
intimately tied to the broken vt220 emulation that we currently have, then
that is a bug in tmux and I never offered to maintain tmux.