[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] about support for more than 16 colors

From: Brand Huntsman
Subject: Re: [Nano-devel] about support for more than 16 colors
Date: Sat, 6 Jan 2018 15:43:35 -0700

On Sat, 6 Jan 2018 21:18:12 +0100
Benno Schulenberg <address@hidden> wrote:

> Playing a bit with color numbers, I now notice that the Linux console
> (a VT) knows only 8 colors, and when 'bright' is added they are more
> intense (the hue doesn't change much, and there is no boldness).  But
> on a terminal emulator (Xfce4-terminal), adding 'bright' changes the
> hue of the color significantly AND it makes the character display in
> bold.

The colors in linux console can be changed in /sys/module/vt/parameters/ and 
terminal emulator colors can be changed in the .Xresources file.

My linux console color also doesn't support bold and many terminal emulators 
don't support it either. And terminal emulators that do support bold require a 
font that supports bold. Same applies to italic.

> All the extra colors (palette indices 16 to 231) can also be bolded,
> but their bolding does not change their hue or brightness.  So... I
> think we will need a new keyword in the color names: bold.  The word
> 'bright' should just mean bright, and 'bold' just bold.  For a Linux
> console, 'bold' will have no effect.  On a terminal emulator 'bold'
> will imply 'bright' for the eight base colors -- not because nano
> chooses that but because that is how ncurses works.  For the extra
> colors (16 to 231), 'bright' will have no effect and should maybe
> not even be allowed.

We should add a new optional field before the fg,bg color field too. So bold 
and bright can be used with the #RRGGBB or palette index colors. The bright 
keyword on fg color would be kept for compatibility, but 'bright' should also 
work in the new attribute field.

Once an attribute field is added, it would be easy to support reverse, 
underline and italic attributes.

I think palette index should be supported along with #RRGGBB mapping. And also 
some color names such as gray0 - gray23 and maybe some names for the 216 
colors, but using the gray0-23 style, not 216 unique color names that no one 
can remember. Support for #RRGGBB wouldn't even be needed if good names can be 

But as I said before, the terminal emulator might not support bold. So the 
bright keyword on the fg color should imply bright and bold in all cases. Using 
a bright or bold attribute would set them independently, but default syntaxes 
shouldn't do this. Any instances of the bold attribute in default syntaxes 
should be accompanied by the bright attribute, to properly map to 16-color 
consoles/terminals without bold support. Could also add a 'bb' attribute that 
bolds and brights.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]