From owner-freebsd-arch@FreeBSD.ORG Thu Mar 6 00:31:13 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C21BBEB for ; Thu, 6 Mar 2014 00:31:13 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A213C277 for ; Thu, 6 Mar 2014 00:31:13 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1WLMDQ-00011R-P6 for freebsd-arch@freebsd.org; Wed, 05 Mar 2014 16:31:12 -0800 Date: Wed, 5 Mar 2014 16:31:12 -0800 (PST) From: "Paul \"LeoNerd\" Evans" To: freebsd-arch@freebsd.org Message-ID: <1394065872771-5892010.post@n5.nabble.com> In-Reply-To: References: <5304A0CC.5000505@FreeBSD.org> <20140223115939.GB4084@aerie.jexium-island.net> Subject: Re: terminfo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 00:31:13 -0000 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. >=20 > - Who cares about send/receive mode? >=20 > - Who cares about 88 colour support? Just use 256 colours. >=20 > - 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. >=20 > People are nowadays only interested in having a 16 or 256 colour, > UTF-8 enabled terminal. >=20 > 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. >=20 > 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 =20 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 a= s much as possible out to the embedding program; all byte IO, keyboard/mouse interaction, and drawing operations. It even optionally abstracts out mallo= c 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 a= s 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 thu= s to provide a solution to cases like Ctrl-Shift-A and Ctrl-I as distinct fro= m Tab. http://www.leonerd.org.uk/hacks/fixterms/ *deep breath* Sorry if the-above comes across as somewhat of a r=E1=BA=BFsum=C3=A9-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 t= o 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 an= y questions or comments. --=20 Paul "LeoNerd" Evans leonerd@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.