terminfo

[Thomas Dickey]

On Fri, Feb 21, 2014 at 01:05:52PM +0100, Ed Schouten wrote:
> Hi Bryan,
> 
> On 19 February 2014 13:17, Bryan Drewery <bdrewery at freebsd.org> wrote:
> > Why do we not use terminfo? Our termcap is quite aged and missing a lot
> > of modern terminals/clients.
> 
> 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?

hmm - I continue to add/improve the database (and always have todo's)

http://invisible-island.net/ncurses/terminfo.src-history.html

> > 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?
> 
> It's just a matter of someone doing the work. It would be nice if we
> ever made this change.

It's more than that - there's some reluctance of the users to switch
to terminfo.  So what FreeBSD has is a facade wrapped around terminfo,
with the legacy termcap database updated occasionally.
 
> 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.

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

:-)

-- 
Thomas E. Dickey <dickey at invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140223/57d09270/attachment.sig>