terminfo

[Paul "LeoNerd" Evans]

Ed Schouten-3 wrote
> - 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.

I'm with you on all those points.


Ed Schouten-3 wrote
> 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.

I believe that may be where I come in.

Two of my larger current projects are a terminal emulator, and a terminal
emulation library; two parts of this particular issue.

libvterm is a totally-abstracted library in pure C99 that aims to entirely
emulate a VTxxx/xterm and similar terminals.
  https://launchpad.net/libvterm/

This isn't entirely finished yet but already it understands the vast
majority of sequences actually found in the wild. The list of sequences it
currently understands (as compared VT1xx, 2xx, etc..) can be found at
 
http://bazaar.launchpad.net/~leonerd/libvterm/trunk/view/head:/doc/seqs.txt
(a document not entirely unlike xterm's ctlseqs ;) )

Of particular interest to FreeBSD may be the fact that libvterm abstracts as
much as possible out to the embedding program; all byte IO, keyboard/mouse
interaction, and drawing operations. It even optionally abstracts out malloc
itself, and makes special care not to call the allocator function on the
"critical" path of normal drawing; this is only used for initialisation and
resize. This feature I intended specially for use in things like UNIX
kernels, as sometimes they have critical memory requirements.

((This library also drives, among others, pangoterm, a GTK-based terminal I
wrote around it as proof-of-concept. This terminal has been my one terminal
I've actually used for both personal and work use, for the past two years:
  https://launchpad.net/pangoterm
But to be clear - all the clever "understanding terminal stuff" happens in
the abstracted libvterm library; the actual GTK program is a tiny wrapper
that basically just provides "put these letters here in these
colours/attributes" functions.))

I've also been working on the "terminal UI applications" end of the chain,
by writing a set of libraries that programs can use for driving a terminal,
which more completely understand these modern features of terminals, such as
provided by libvterm.
  http://www.leonerd.org.uk/code/libtickit/

This aims to provide support at a number of increasingly-abstracted levels,
though right now only the lowermost (the raw "terminal" level) is available
in the C library. The remaining (the "window" and "widget" levels) are
currently implemented in the Perl module of the same name (Tickit on CPAN),
where I'm developing it, slowly migrating code as I go into the C library.

Inbetween the two I have been trying my best to both follow and implement
"current" terminal technology, as exemplified by xterm and compatible, and
also to extend it where it makes sense - for example, my definition of CSI u
to allow terminals to encode arbitrary modified Unicode keypresses, and thus
to provide a solution to cases like Ctrl-Shift-A and Ctrl-I as distinct from
Tab.
  http://www.leonerd.org.uk/hacks/fixterms/


*deep breath*

Sorry if the-above comes across as somewhat of a rếsumé-style advert or
shameless self-promotion. I was pointed at this thread because of a
terminal-based discussion in Freenode's #vim, where I'm usually the person
to field any kind of terminal-related question, often with reference to one
or more of my projects above. I got to this point in the message thread and
felt I should reply and speak up, if only to say "Hey, so yes I am trying to
be this person who cares about modern terminal technology and wishes to see
it continue to expand and grow into the 21st century".

So if I can be of any assistance with these issues, I'd be happy to take any
questions or comments.

-- 

Paul "LeoNerd" Evans

leonerd at leonerd.org.uk
http://www.leonerd.org.uk/




--
View this message in context: http://freebsd.1045724.n5.nabble.com/terminfo-tp5887280p5892010.html
Sent from the freebsd-arch mailing list archive at Nabble.com.