Re: A wide range of terminals that can do italics
On Sat, Sep 03, 2016 at 12:44:36PM +0100, Jonathan de Boyne Pollard wrote:
> Adam Borowski:
>
> >Hmm... 1 out of 11¹ implementing italics plus one doing some other thing
> >doesn't strike me as a "wide" range.
> >
> >I didn't bother to test terminals I don't have installed at the moment but
> >the above sample shouldn't be much off.
> >
> Aside from the tests in your list that you somehow got wrong, as M.
> Thibault has already pointed out, you've actually managed to carefully
> pick some of the very terminal emulators (the terminal emulator programs
> in the Linux, FreeBSD, and OpenBSD kernels) [...] So yes, you've got quite
> a skewed sample there and it is rather off.
I did not pick them intentionally, it was just 100% of what I have installed
on my machine (actually, there might be a gnome-terminal on an Ubuntu or
Fedora default install in a VM, I've got a large array of those but not
really any with some customization; I have skipped hurd, kfreebsd and real
FreeBSD consoles to count hardware VGA console just once). So it was just
bad luck, although it was so extreme I think I should do a real exhaustive
check. Would using popcon vote (Debian only) for weighting be reasonable?
> that the nosh user-space virtual terminal system is aimed at replacing,
> with full ECMA-48 attribute support being one of the very features that it
> has in comparison to them.
I don't think this is a good idea. When your userspace is working, you can
as well use full-blown X (or mir or weyland-yutani if that fancies you).
Not sure about you but I prefer to do most of the work on server setup from
a comfy chair, leaving that new box the moment its filesystems are set, it
boots and has ssh. This means, both on my main desktop and on servers I see
the text console only once shit has happened. This means failing during
boot, with bare kernel, either before initrd, in initrd or booted single,
perhaps with The Only True Init™ (/bin/bash) (let's not argue which of real
inits fails worse). Ie, most daemons are not working, and thus that fancy
user-space console will not be there.
The in-kernel console is vital for such recovery tasks. And because of
limitations of hardware VGA text mode (on PCs), you're limited to 256 glyphs
with attributes limited to 8 foregrounds colors, foreground brightness, 8
background colors, blink; foreground brightness (but no other bit) can be
traded for a second page of 256 glyphs. Yes, you can use that page of
glyphs for italics but I'm not aware of anyone actually implementing that --
most would rather have bright/bold. It's also possible to trade blink for
background brightness, not sure why the kernel doesn't do so.
You can get more once you have framebuffer up, but that can be unreliable on
some hardware, and not during early boot. And the kernel mostly sticks to
VGA capabilities.
Some of us do work on improving the console -- 5 out of my 8 kernel commits
are to drivers/tty/vt/vt.c, but don't expect it to gain fancy features.
It's supposed to be reliable at the cost of bells and whistles.
Meow!
--
Second "wet cat laying down on a powered on box-less SoC on the desk" close
shave in a week. Protect your ARMs, folks!
Reply to: