On 2015-11-28, rdebath <[email protected]> wrote:
> Vim assumed that all terminals that do not have 8, 16, 88 or 256 colours
> have a particular non-ansi, non-terminfo ordering to the first 16 colours.
> Terminals that had one of those counts would only get ANSI ordering if
> the terminfo control sequence ends with a letter "m".
If this is true then it should be changed, regardless of
anything else. The fact that the properties are AB/AF instead
of Sb/Sf implies ANSI ordering to at least the first eight
colors and there's no reasonable precedent for using any other
ordering for the first 16. The existing terminfo entries for any
non-ansi terminal, if containing setab/setaf, already do the
necessary gymnastics to interpret their parameters in ANSI
order. The non-ANSI order should only be used for Sb/Sf, and
avoiding having to do those gymnastics for every ANSI terminal
was the whole *point* of having AB/AF.
Call it TB/TF, I don't think that collides with anyone else's
extensions.
TC is the number of levels per channel. Parameters are from 0 to
TC-1; so we can avoid the mistake that the existing terminfo
descriptions made with initc (which take a parameter from 0 to
1000 despite the fact that the documentation says it's
terminal-dependent and it makes no sense)
TC=256,
TF=\E[38;2;%p1%d;%p2%d;%p3%dm,
TB=\E[48;2;%p1%d;%p2%d;%p3%dm,
Just for fun, here it is for 256-color xterm:
TC=6,
TF=\E[38;5;%p1%{16}%{36}%*%+%p2%{6}%*%+%p3%+%dm
TB=\E[48;5;%p1%{16}%{36}%*%+%p2%{6}%*%+%p3%+%dm
> I have left the weirdness in, but added the assumption that a terminal
> with more than 256 colours will do the sane thing and use the XTerm-256
> ordering for the first 256 of these colours.
Why not just go all the way and actually implement true-color
support (invent a new property that accepts three parameters)
instead of using an elaborate terminfo string that fakes it?
> If it does not, terminfo is sufficiently programmable to make it happen.
What if I want more colors? Or less?
If going for this approach, why not get rid of the xterm color
cube and just immediately place your cube and your grays after
the first sixteen, for a total of 4368? What about an 88-color
xterm cube, for 4440 supported colors? Why not a cube with 17
levels (0, 15, 30, ..., 255)? Or 31 levels (29791 colors)
either not spaced exactly equally, or not fully covering 0..255
(suppose 4, 12, 20, ..., 252)?
We could bikeshed this forever, and I don't see the value of any of it
compared to actually supporting true color.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
