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

This conversation is not about the xterm(1) codebase, but about the
blended-minimum spread through the display handlers doing xterm.
There has to be a minimum, to support TERM=xterm.

I believe we can achieve that minimum, rather than maintaining a
weird vt220 backend which is _already receiving the escape sequences
because the reality is TERM=xterm.

TERM=xterm is the very common.
The other common thing, ONLY ON CONSOLE, is TERM=vt220

Why have one codebase which needs to cater to both modes, on the fly?