Re: Support for 256 colors in zsh/curses

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

The "a/b" should be "x/y", so:

Hello,
the existing infrastructure in zsh/curses is quite nice. If user
requests color pair "x/y", it is first looked up in a hash table:

!(cpn = (Colorpairnode) gethashnode2(zcurses_colorpairs, colorpair))) {

if it doesn't exist, then "x/y" (e.g. "red/black") is translated to
corresponding integers, and init_pair is called:

if (next_cp >= COLOR_PAIRS || init_pair(next_cp, f, b) == ERR)  {

where "f" and "b" are the translated integers. The color pair is put
into the hash under "x/y" for future reuse.

On 29 April 2016 at 13:34, Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx> wrote:
> Hello,
> the existing infrastructure in zsh/curses is quite nice. If user
> requests color pair "a/b", it is first looked up in a hash table:
>
> !(cpn = (Colorpairnode) gethashnode2(zcurses_colorpairs, colorpair))) {
>
> if it doesn't exist, then "x/y" (e.g. "red/black") is translated to
> corresponding integers, and init_pair is called:
>
> if (next_cp >= COLOR_PAIRS || init_pair(next_cp, f, b) == ERR)  {
>
> where "f" and "b" are the translated integers. The color pair is put
> into the hash under "x/y" for future reuse.
>
>
> To support 256 colors, all I had to do is translate num1/num2 into
> f=num1, b=num2, i.e. just directly (classic atoi) translate color
> number into integer to be passed to curses as its color number. Not
> sure what else can I write, reading the code will reveal how
> transparent the change is. Any questions maybe?
>
> Best regards,
> Sebastian Gniazdowski