Re: [Nano-devel] A patch for added color support

[nano]

On 01/01/18 12:04, Brand Huntsman wrote:

On Sun, 31 Dec 2017 21:50:24 +1030 address@hidden wrote:

I would thus prefer/like to see:   color cyan regex superseded by something like one of the following:   color rgb(0,255,255) regex   color 0,255,255 regex

The 16 color names should remain for 16-color support.

Agreed.

I don't know how other editors handle 256-color, but an unsigned 0-255 decimal would probably work.

From what I've read that is the way it's done.

And then rgb(0-255,0-255,0-255) and #FFFFFF could be added for true color support. But supporting "255,255,255" is a terrible idea, how would you do a background color? "black,white" -> "0,0,0,255,255,255"?

The foreground/background delimiter doesn't need to be a comma.  Could just as easily be an underscore (thus 0,0,0_255,255,255) or any other character that makes things legible and is easy/safe to process.  I don't have a personal preference.

That said, if you just wanted black on white, then I'd continue to use "black,white".  :)

Once you go beyond the 8 basic colours and their bright equivalents, however, all bets are off as far as colour names are concerned.  I doubt there's anyone in the world who can name all 256 on an 8-bit palette.  And even on an 8-bit palette, if you wanted to specify 'purple' (for example) you'd still have to work out which of the 8 or so purples you actually wanted.  Names are pretty-much hopeless on an 8-bit palette.  Even more-so on a 24-bit palette.  Both are almost purely a numerical affair.

The mapping of 24-bit nanorc syntax colours to the resolution supported by the terminal could, and I feel /should/, be done programmatically within nano.

Is it possible for nano to query the 16/256-color palette?

One person I know of blogged about this in detail and actually did come up with a way to probe the actual capabilities of the terminal and see what was actually possible — but because of the "inconsistent delay in responses" he did not recommend the approach for production purposes.  Ultimately the best approach he (and others) could come up with was just making sure that the terminal reported its colour capabilities correctly (via $TERM etc).

Might be best to throw an error if 24-bit color or 256-color is used on a terminal emulator that doesn't support them.

That shouldn't even be possible.  nano would only use 24-bit, or map down to 8-bit, if the terminal already declared support for those resolutions.

I wouldn't use a true-color image for my desktop background on a 16-color monitor, so why would I use a true-color syntax on a 16-color terminal emulator?

You wouldn't need to, and no-one would be forcing you to.  If all you need is 16 colours then keep using the current system.  There's no reason anyone should expend labour to remove a capability from nano unless it's causing problems or just isn't being used — neither of which apply in this case.

The proposal is simply to extend the current capability of nano to read 24-bit rgb codes, so that (unlike yourself) those people that do use nano on terminals with 8- or 24-bit capabilities can take advantage of them to enhance their productivity.

Cheers,

Tim