terminfo

[John D. Hendrickson and Sara Darnell]

how do PEOPLE login remotely over serial line after you INTENTIONALLY 
  break send / receive ??

is it your job to break things that already work for others for your 
own personal satisfaction ?

no.

and since when is VT52 a default in BSD ? it isn't

since when does everyone need your dependance on number of colors. 
they don't and may be bothered by ANY color

....



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 charactersPaul "LeoNerd" Evans wrote:
> 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.
>