From: Thomas Dickey Subject: Re: wscons 256 colour support To: Ingo Schwarze Cc: tech@openbsd.org Date: Sun, 29 Jun 2025 05:56:31 -0400 Reply-To: dickey@his.com On Sat, Jun 28, 2025 at 06:59:47PM +0200, Ingo Schwarze wrote: > 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'm expecting the usual issues with incompatbility. https://invisible-island.net/ncurses/ncurses.faq.html#xterm_generic You may surprise me. > I did not check anything specifically for this mail, but last time > i looked, xterm(1) supported interminable lists of escape sequences. interminable has a specific meaning - perhaps you should consult a dictionary > 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 some would differ (some of that is tables, which isn't generally considered "code", for example). I've been developing xterm since January 1996. Its rate of growth has not increased. Just looking at C code: 109944 30557 current (patch #400) 88295 24567 patch #319, August 2015 56644 14156 patch #203, July 2005 27345 8091 July 1996 the numbers tell me that the rate has decreased. Of course, OpenBSD has also grown. Just looking at xenocara, I see it growing more rapidly than xterm: 10486735 2247505 current 4589210 1466345 July 2015 1941095 622423 November 2006 (initial commit, with xterm #216) Looking at src, I see a similar rate of growth, which also exceeds xterm's 20519369 4459751 current 11496469 3318205 June 30, 2015 9299651 2787142 June 30, 2005 3234500 1010247 January 31, 1996 > code growth is new compatibilty code catering to historical terminals, > some fraction of the new code is also introducing new functionality, specifics help for discussion. I make a lot of that compile-time optional, to cater to niches such as this. If you have a constructive suggestion, I'll respond to that. > 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 I don't see a bug report, nor any constructive comments on this list which I could use in that regard. Your comments do not acknowlege my fix in patch #399 - May 18 (which Matthieu committed two weeks ago). -- Thomas E. Dickey https://invisible-island.net