Date: Sun, 23 Feb 2014 14:49:25 +0100 From: Ed Schouten <ed@80386.nl> To: dickey@his.com Cc: arch@freebsd.org, Bryan Drewery <bdrewery@freebsd.org> Subject: Re: terminfo Message-ID: <CAJOYFBB_K0ziNaTg=ThnCBN1EPU-b_H2kUxsc-MPYNEJHb3Y7w@mail.gmail.com> In-Reply-To: <20140223115939.GB4084@aerie.jexium-island.net> References: <5304A0CC.5000505@FreeBSD.org> <CAJOYFBCMS4k7pyRk2YHZm81F6iP=SApZhbCm0MO4P-pvXbTCxQ@mail.gmail.com> <20140223115939.GB4084@aerie.jexium-island.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Thomas, On 23 February 2014 12:59, Thomas Dickey <dickey@his.com> wrote: >> 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, > > I'm inclined to disagree with that. > > Here's a working entry for the console, along with notes: > > http://invisible-island.net/ncurses/terminfo.src.html#tic-teken > > (though I see that I overlooked adding the note which I made for wsvt25, > that none of the xterm-specific items is supported). > > Counting differences using infocmp: > versus cons25 (37 lines) > versus xterm-new (120 lines) > > One of the differences against cons25 is partial, as noted in my comments > on acsc - there's no corresponding adjustment to make against xterm. This terminfo entry is incorrect. It will make ACS work on a standard setup where the user has the BIOS CP437 font loaded, but will break horribly if a user uses a different character set, like ISO-8859-1. There is a reason why syscons displays ASCII characters for ACS box drawing, namely that there is no guarantee that the actual font loaded into the graphics card has any ACS characters to begin with. >> which is why we use TERM=xterm. 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. >> >> I suspect the following logic would be sufficient for at least 99.5% >> of our users: >> >> if $TERM contains 256 >> use xterm-256color >> else >> use xterm > > I didn't see any 256-color support in testing this configuration. > It does _something_, but would tend to disappoint users. > > ftp://invisible-island.net/temp/teken-88colors.png > ftp://invisible-island.net/temp/teken-256colors.png > > (screenshots made using VMware Fusion with FreeBSD 10 - ymmv) As I mentioned before, teken supports 256 colours internally, but this is sampled down to 8 different colours later on. This is due to the fact that syscons only reserves 1 byte per cell to keep track of display attributes, which is not sufficient to keep track of 256 foreground colours, 256 background colours and bold, blink, etc. >> 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. >> >> $TERM should die. > > certainly not while there are such large differences among the implementations. > > :-) And I think that these differences only exist, because -- don't take this as a personal insult, please read on -- the maintainer of terminfo/ncurses/vttest has done little to nothing to introduce any convergence of implementations over time. I think the comment you've added above the termcap entry and this email demonstrate this. Because realistically speaking: - Who cares about VT52 support? Those things are from the Viking Age. - Who cares about double-width characters? I don't know a single program that uses this. In the worst case, you can just use fullwidth CJK for certain characters. - Who cares about send/receive mode? - Who cares about 88 colour support? Just use 256 colours. - Who cares about ACS? Unicode already has those characters. There are so many legacy features out there, that nobody actually *knows* how terminals should behave anymore. Also combined with the fact that the de facto reference implementation of terminal emulation (i.e., xterm) cannot easily be decoupled from X11, people just make stuff up. People are nowadays only interested in having a 16 or 256 colour, UTF-8 enabled terminal. It would be so incredibly easy for you as the maintainer of terminfo to say: "Here's an ideal terminfo entry. It's compact, easy to implement, etc. This is how I want terminals to behave. And this menu in vttest can be used to easily test conformance." Then you just file bugs against the authors of commonly used terminal emulators and 3-5 years later, the ecosystem has converged. Done. As I mentioned before, my spare time is limited nowadays, but if you would be interested in doing something like that, I would be more than interested to get this sorted out on FreeBSD's side. -- Ed Schouten <ed@80386.nl>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJOYFBB_K0ziNaTg=ThnCBN1EPU-b_H2kUxsc-MPYNEJHb3Y7w>