Hello,

Theo de Raadt wrote on Sat, Jun 28, 2025 at 08:33:37AM -0600:
> Crystal Kolipe <kolipe.c@exoticsilicon.com> wrote:
>> On Sat, Jun 28, 2025 at 08:13:40AM -0600, Theo de Raadt wrote:

>>> - Basic compatibility with xterm
>>> - So that we can change the default tty type to xterm, and stop
>>>   saying "vt220" in /etc/ttys, and say "xterm" instead.

>> What is still missing for this to happen?

> I don't know.

>> The main thing I am aware of is the F-keys patch that I posted separately.

> I doubt that is in the critical path.  I suspect the problems will be that
> programs assume they can send xterm sequences which are mis-executed.

I did not check anything specifically for this mail, but last time
i looked, xterm(1) supported interminable lists of escape sequences.
On top of that, the xerm(1) codebase is growing at a very fast pace,
several thousand lines of new code per year.  While much of that
code growth is new compatibilty code catering to historical terminals,
some fraction of the new code is also introducing new functionality,
and the direction xterm(1) is going absolutely does not feel sane
to me, neither regarding the fast-growing code for historical
compatibility, and even less so regarding the new functionality.
The xterm(1) we currently have in the tree is not even safe for
everyday use with the default configuration.  Having such functionality
in wscons(4) - i.e. in the kernel - would seem highly undesirable
to me.

Either way, even assuming that wscons(4) currently implements full
vt220 compatibility (i did not check), i would certainly expect
that switching from full vt220 compatibility to full xterm(1)
compatibilty would result in code that would be larger by quite a
significant margin.  That in addition to the new features being
mostly undesirable, plus likely to continue growing in the future.

I did check two of the new unsafe misfeatures that xterm(1) currently
has enabled by default (C1 control characters in both ISO-LATIN and
UTF-8 encoding, both corrupting the output).  Currently, wscons(4)
appears to suffer from neither of these two, so at least that would
require some new code.  Or better, not!

> How else do we avoid the codebase becoming a bloaty kitchen-sink
> which noone needs?  My argument would be that if it says it is vt220,
> it should ONLY support vt220 operations.  If it says it is xterm,
> only xterm operations.

While that sounds fair at face value, it would likely also be fair
to call xterm itself a "kitchen sink".  Maybe that's even generous,
in the sense that xterm has likely become worse than a kitchen sink
by now.

Yours,
  Ingo