From: Ingo Schwarze Subject: Re: wscons 256 colour support To: Theo de Raadt Cc: Mark Kettenis , tech@openbsd.org Date: Sat, 28 Jun 2025 18:59:47 +0200 Hello, Theo de Raadt wrote on Sat, Jun 28, 2025 at 08:33:37AM -0600: > Crystal Kolipe 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