Date: Wed, 12 Mar 2014 19:24:20 -0500 From: "John D. Hendrickson and Sara Darnell" <johnandsara2@cox.net> To: "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> Cc: freebsd-arch@freebsd.org Subject: Re: terminfo Message-ID: <5320FAB4.6040909@cox.net> In-Reply-To: <a0XK1n00f2X408g010XL9G> References: <5304A0CC.5000505@FreeBSD.org> <CAJOYFBCMS4k7pyRk2YHZm81F6iP=SApZhbCm0MO4P-pvXbTCxQ@mail.gmail.com> <20140223115939.GB4084@aerie.jexium-island.net> <CAJOYFBB_K0ziNaTg=ThnCBN1EPU-b_H2kUxsc-MPYNEJHb3Y7w@mail.gmail.com> <a0XK1n00f2X408g010XL9G>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5320FAB4.6040909>