From: Sebastian Gniazdowski <sgniazdowski@gmail.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [PATCH] Support true colours via termcap interface
Date: Thu, 7 Feb 2019 08:36:50 +0100 [thread overview]
Message-ID: <CAKc7PVDXeKL4aROWTt+tWhhykfqKrwOud1jxKMPkOxHC806OOw@mail.gmail.com> (raw)
In-Reply-To: <20190204212123.mpzkt4bpajx2cxpw@Daniels-MacBook-Air.local>
On Mon, 4 Feb 2019 at 22:22, Daniel Tameling <tamelingdaniel@gmail.com> wrote:
>
> On Mon, Feb 04, 2019 at 09:11:04AM +0100, Sebastian Gniazdowski wrote:
> > On Mon, 4 Feb 2019 at 07:20, Daniel Tameling <tamelingdaniel@gmail.com> wrote:
> But I also noticed that my patch breaks the is_default_zle_highlight =
> 0 code. It doesn't set use_truecolor for the #ffcc00 syntax.
Could you restore the is_default_zle_highlight to its functioning state?
> But that
> is not the only problem: with a true colour terminal, one expects
> colours beyond 255 to work, e.g. via fg=273. In that case one also has
> to use the true colour escape sequence. Then also colours in the range
> from 8 to 255 should use this sequence. But colours from 0 to 7 should
> probably still be the standard ansi sequence, like ncurses does it.
>
> One could achieve that by modifying the if(use_truecolor) checks when
> the escape sequence is constructed manually. Alternatively, the patch
> below should accomplish the same. Now zlehighlight.ztst fails at the
> same point as without the patch for xterm-direct. It seems that this
> is because the non-termcap code emits only the standard true colour
> escape sequence, which cannot be modified like the other ones.
>
> --
> Best regards,
> Daniel
>
>
> diff --git a/Src/prompt.c b/Src/prompt.c
> index f2b3f161e..bef53b148 100644
> --- a/Src/prompt.c
> +++ b/Src/prompt.c
> @@ -1652,6 +1652,13 @@ match_colour(const char **teststrp, int is_fg, int colour)
> colour = runhookdef(GETCOLORATTR, &color) - 1;
> if (colour == -1) { /* no hook function added, try true color (24-bit) */
> colour = (((color.red << 8) + color.green) << 8) + color.blue;
> + /*
> + * If we have a true colour termcap entry and colour > 7
> + * use termcap; for colours 0-7 termcap usually emits the
> + * standard ANSI sequences; we don't want that.
> + */
> + if (tccolours == 0x1000000 && colour > 7)
> + on |= is_fg ? TXT_ATTR_FG_TERMCAP : TXT_ATTR_BG_TERMCAP;
> return on | (is_fg ? TXT_ATTR_FG_24BIT : TXT_ATTR_BG_24BIT) |
> (zattr)colour << shft;
> } else if (colour <= -2) {
> @@ -1668,7 +1675,7 @@ match_colour(const char **teststrp, int is_fg, int colour)
> }
> else {
> colour = (int)zstrtol(*teststrp, (char **)teststrp, 10);
> - if (colour < 0 || colour >= 256)
> + if (colour < 0 || colour >= tccolours)
> return TXT_ERROR;
> }
> }
> @@ -1692,6 +1699,16 @@ match_colour(const char **teststrp, int is_fg, int colour)
> */
> on |= is_fg ? TXT_ATTR_FG_TERMCAP :
> TXT_ATTR_BG_TERMCAP;
> + /*
> + * If our terminal supports more than 256 colours it is
> + * most likely a true colour terminal (it's not always
> + * 256*256*256 colours: sometimes tccolours get truncated
> + * to the largest short, which is significantly smaller);
> + * if we don't use termcap, we want to emit true colour
> + * escape sequences for colour > 7.
> + */
> + if (tccolours > 256 && colour > 7)
> + on |= is_fg ? TXT_ATTR_FG_24BIT : TXT_ATTR_BG_24BIT;
> }
> }
> return on | (zattr)colour << shft;
> @@ -2039,8 +2056,7 @@ set_colour_attribute(zattr atr, int fg_bg, int flags)
> * highlighting variables, so much of this shouldn't be
> * necessary at this point, but we might as well be safe.
> */
> - if (!def && !use_truecolor &&
> - (is_default_zle_highlight && (colour > 7 || use_termcap)))
> + if (!def && (is_default_zle_highlight && (colour > 7 || use_termcap)))
> {
> /*
> * We can if it's available, and either we couldn't get
--
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org
next prev parent reply other threads:[~2019-02-07 7:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-03 21:57 Daniel Tameling
2019-02-04 2:15 ` Sebastian Gniazdowski
2019-02-04 6:19 ` Daniel Tameling
2019-02-04 8:11 ` Sebastian Gniazdowski
2019-02-04 21:21 ` Daniel Tameling
2019-02-07 7:36 ` Sebastian Gniazdowski [this message]
2019-02-07 20:32 ` Daniel Tameling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKc7PVDXeKL4aROWTt+tWhhykfqKrwOud1jxKMPkOxHC806OOw@mail.gmail.com \
--to=sgniazdowski@gmail.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).