Re: [PATCH] Support true colours via termcap interface

[Daniel Tameling <tamelingdaniel@xxxxxxxxx>]

On Mon, Feb 04, 2019 at 03:15:13AM +0100, Sebastian Gniazdowski wrote:
> > @@ -1652,8 +1652,10 @@ match_colour(const char **teststrp, int is_fg, int colour)
> On Sun, 3 Feb 2019 at 22:57, Daniel Tameling <tamelingdaniel@xxxxxxxxx> wrote:
> >
> > Dear all,
> >
> > ncurses recently added support for 24 bit colour terminals. It kind of
> > works out of the box with zsh, except for the hardcoded 256 colour
> > limit in match_colour. olor.red << 8) + color.green) << 8) + color.blue;
> (...)
> >
> > -               return on | (is_fg ? TXT_ATTR_FG_24BIT : TXT_ATTR_BG_24BIT) |
> > -                       (zattr)colour << shft;
> > +                if (tccolours != 0x1000000 || colour < 8) {
> > +                        return on | (is_fg ? TXT_ATTR_FG_24BIT :
> > +                                     TXT_ATTR_BG_24BIT) | (zattr)colour << shft;
> > +                }
> >             } else if (colour <= -2) {
> >                 return TXT_ERROR;
> >             }
> 
> I wonder what this change causes. Because to use the termcap for 24
> bit sequences, noe would have to lessen the following conditions in
> set_colour_attribute():
> 
> Line 2040:     if (!def && !use_truecolor &&
> Line 2041:        (is_default_zle_highlight && (colour > 7 || use_termcap)))
> Line 2042:    {
> 
> I.e. remove  or in other way lessen the use_truecolor condition.
> Without this the true color output will be bypassing termcap.

That is not necessary. use_truecolor is false and use_termcap is true,
because TXT_ATTR_FG_24BIT isn't returned by match_colour but
TXT_ATTR_FG_TERMCAP.

Btw. I did that deliberately. I didn't want to make the if even more
complicated and I wanted to use the same code path as for the
%F{16763955} syntax. Making a small change to match_colour felt nicer
than to hack around in set_colour_attribute.

> 
> Currently, the code  `print -P %F{16763955} ' DOESN'T work, so your
> change does something that makes it working

It doesn't work because match_colour currently returns TXT_ERROR for
this sort of syntax if colour >= 256.

> , however the first code
> example:
> 
> print -P %F{'#ffcc33'} test
> 
> Works with current code (ie. without the patch).

Well, it works differently:

Before the patch, the hardcoded escape sequence is used: 
$ TERM=xterm-direct print -P %F{'#ffcc00'} | cat -v
^[[38;2;255;204;0m

Afterwards the terminfo entry is used:
$ TERM=xterm-direct print -P %F{'#ffcc33'} | cat -v
^[[38:2::255:204:51m

The former works because xterm understands both escape sequences, but
that might not be the case for all terminals out there. It seems that
right now all terminals that deviate from the former syntax still
interpret it correctly. But there is no guarantee that the situation
will stay this way. In general, it should be more future proof to use
the termcap entry if it is available.

-- 
Best regards,
Daniel