Date: Fri, 21 Feb 2014 12:14:35 -0700 From: Warner Losh <wlosh@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: Ed Schouten <ed@80386.nl>, Bryan Drewery <bdrewery@FreeBSD.org>, arch@FreeBSD.org Subject: Re: terminfo Message-ID: <C5D5EB8F-93FA-419A-B3B9-F4E53EEEB220@bsdimp.com> In-Reply-To: <1392997589.1145.91.camel@revolution.hippie.lan> References: <5304A0CC.5000505@FreeBSD.org> <CAJOYFBCMS4k7pyRk2YHZm81F6iP=SApZhbCm0MO4P-pvXbTCxQ@mail.gmail.com> <1392997589.1145.91.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 21, 2014, at 8:46 AM, Ian Lepore wrote: > On Fri, 2014-02-21 at 13:05 +0100, Ed Schouten wrote: >> Hi Bryan, >>=20 >> On 19 February 2014 13:17, Bryan Drewery <bdrewery@freebsd.org> = wrote: >>> Why do we not use terminfo? Our termcap is quite aged and missing a = lot >>> of modern terminals/clients. >>=20 >> It is true that our termcap is quite aged, but the fact is, once you >> add entries for a certain terminal, there's little need to update it >> after that. ncurses itself is not really a moving target. What kind = of >> modern terminals/clients are missing? >>=20 >>> Using terminfo would allow us to use the already well maintained = database from ncurses. Is it just a matter of someone doing the work or = are there other reasons? >>=20 >> It's just a matter of someone doing the work. It would be nice if we >> ever made this change. >>=20 >> On the other hand, I might have a radical point of view here: maybe = we >> could consider taking the approach of sticking to termcap and >> installing /etc/termcap.small as the system's default termcap. Or >> maybe patch up our termcap routines to just hardcode the sequences. >>=20 >> I won't deny that termcap was really useful at one point in time, but >> let's be honest: the variety of terminals out there has massively >> dropped over time. Terminal emulation has become a solved problem. As >> of FreeBSD 9, syscons supports all the sequences described in >> xterm-256color, though it isn't able to print more than 8 colours, >> which is why we use TERM=3Dxterm. Tools like screen, tmux, etc., they >> use a different TERM type, but this is mainly used to detect whether >> the process is running inside of screen or tmux. It does not strongly >> affect the kinds of sequences that are being emitted. They work >> perfectly fine if you just set TERM to xterm or xterm-256color. >>=20 >> I suspect the following logic would be sufficient for at least 99.5% >> of our users: >>=20 >> if $TERM contains 256 >> use xterm-256color >> else >> use xterm >>=20 >> It's a shame I am so short on time nowadays, but I think it would = make >> so much sense to just come up with some kind of document that >> standardizes the intersection of the features supported by most = common >> terminal emulators and get it rubber stamped by the maintainers of >> various terminal emulators. If it turns out some kind of terminal >> emulator does something in a non-standard way, we can just slap this >> document in the author's face. That would not only benefit FreeBSD, >> but also most of the other flavours of UNIX. >>=20 >> $TERM should die. >>=20 >=20 > All of that seems to assume that every terminal actually being used in > the world today is either xterm or something that emulates it. Try > using vi on a serial console on an embedded ARM board and you'll get a > quick frustrating lesson in how not-xterm a serial console is. I've = yet > to find a combo of serial comms program and TERM setting that actually > works well and lets you edit a file with vi. I'd go so far as to say that no such subset actually exists. There's = nothing wrong with TERM, and it has abstracted away all the differences = for many, many years. I've had good luck with TERM=3Dvt100 in those situations, but I use tip = and apart from eating ^P it does a good job of being transparent = enough... Let's not kill $TERM... There seems to be no benefit, and lots of pain. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C5D5EB8F-93FA-419A-B3B9-F4E53EEEB220>