nosh version 1.12

[Jonathan de Boyne Pollard]

nosh is now up to version 1.12

* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html

As I wrote before:  If you also read the worked example, make sure that 
you read all of the way to the bottom.  (-:  If you want to read more, 
there's a whole Guide in the package, and lots of manual pages.

I missed out the annoucements for 1.10 and 1.11.  There have been quite 
a lot of additions, but concentrated in some very specific areas of the 
package.

The developers of the "vt" subsystem in the kernel might be pleased to 
learn that the console-fb-realizer in nosh uses the same font format, 
and can use the supplied vt fonts.  I myself use the 9x15 and 9x15B 
"misc fixed" fonts published by Markus Kuhn, as converted from BDF by 
"vtfontcvt".  The keyboard map compiler, similarly, compiles kbdmap(5) 
files.

Of course, there aren't the constraints in applications mode programming 
that there are in kernel mode programming.  So console-fb-realizer can 
load multiple fonts, can do true italics (SGR 3), distinguishes italic 
from oblique, can use a true italic font (as long as it is monospace of 
course), does 24-bit RGB colour, overlays the BSD kbdmaps on top of an 
ISO 9995-3 "common secondary group", does Unicode dead keys, and does 
ISO 9993-5 so-called "peculiar" dead keys.  If at this point you are 
wondering what console-fb-realizer is, crank up your favourite HTML 
viewer, point it at the nosh Guide, and read about user-space virtual 
terminals, made up of console-fb-realizer, console-terminal-emulator, 
console-multiplexor, and your choice of tty login program.  Yes, it's 
intentionally decomposable.  Yes, you can change realizers on the fly 
without affecting running programs.  Yes, the number of multiplexed 
virtual terminals can be changed on the fly.  Yes, it does UTF-8.  Yes, 
it's BSD licensed.  Yes, it's designed so that one can do interesting 
things like plug in BRLTTY and not need screen.

* 
http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/brltty.html

As well as being compatible with the control sequences for the FreeBSD 
and Linux consoles (minus some highly device-specific stuff that really 
only applies if one is using real PC hardware with things like VGA 
registers and whatnot), console-terminal-emulator understands the 
DECSCPP and DECSNLS control sequences for changing screen sizes, has 
programmable background-colour erase, and has the DECBKM mode switch.  
In support of the latter, the compiler provides a "bspace" extension to 
kbdmap(5) files for doing the right thing when the backspace key is 
pressed.

In other news:  The previously FreeBSD-specific VirtualBox guest 
services services (sic!) are now more platform-agnostic.  The fact that 
some of these services are kernel modules inspired the creation of a 
simple, minimal, but (importantly) portable load-kernel-module tool.  
Other new services include a set of OpenStack service bundles.  And the 
convert-ttys-presets tool allows one to import from /etc/ttys to a set 
of ttylogin service bundles.

Have some free bug reports that resulted from this:
  * kbdmap(5) documents 35 ASCII control characters.  It uses the name 
"np" for Form Feed, which is a bit confusing when one is in the ECMA-48 
world of terminals, since NP is the name of a quite different control 
sequence in ECMA-48.  ECMA-48 uses FF for Form Feed.  None of the 
FreeBSD 10 keymaps that I've looked at actually use "np". Meanwhile, 32 
C0 control characters plus SPACE and DEL is of course 34.  I'll leave it 
as an exercise to the reader to discover the extra bogus 35th ASCII 
control character that the FreeBSD manual just invents from whole 
cloth.  The answer can be found in the source for the 
console-convert-kbdmap tool.  (-:
* In contrast, many of the keymaps use "nop", but that's not documented 
in the man page at all.
* For some reason, the higher numbered function keys (F13 and above) on 
the FreeBSD kernel terminal emulator still generate the SCO XENIX 
control sequences, even when the lower numbered function keys generate 
the DEC VT sequences.  I didn't replicate this behaviour, because it 
looks like a simple bug where the higher numbered function keys have 
been overlooked during DECification. console-terminal-emulator generates 
DEC VT sequences for all function keys from F1 to F22 when in DEC VT mode.
* It turns out that clang++ lets one static_cast<> away constness 
sometimes when it shouldn't.

You'll need to use syscons for console-fb-realizer until I get to the 
bottom of the ioctl() problem that it encounters with vt.  And I know 
about the keyboard LEDs.