From: Sebastian Gniazdowski <sgniazdowski@gmail.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: [PATCH] Make 256 color codes be based on zle_highlight array, not on termcap
Date: Sat, 8 Dec 2018 23:04:33 +0100 [thread overview]
Message-ID: <CAKc7PVBUFSujsBRHi_wbC2zZZp18QdW=1MnrgRzGC+S7T1xEgw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]
Hello,
zle_highlight array has fields like `fg_start_code' & `fg_end_code'.
The first is by default $'\x1b[', the second - 'm'.
ANSI colors and True-Colors are using those fields to construct and
emit the final, complete escape (by default) code to the terminal.
Yet the 248 colors are ignoring zle_highlight and are equipped with
terminal code by use of termcap. I think the following line (prompt.c:
~2044) does the conversion:
tputs(tgoto(tcstr[tc], colour, colour), 1, putshout);
The patch makes the 256 colors to also use zle_highlight. This is the
main addition of the patch (also included the TrueColor case, to show
that this is done exactly this way):
} else if (use_truecolor) {
ptr += sprintf(ptr, "8;2;%d;%d;%d", colour >> 16,
(colour >> 8) & 0xff, colour & 0xff);
+ } else if (colour > 7 && colour <= 255) {
+ ptr += sprintf(ptr, "8;5;%d", colour);
Is the patch acceptable? I imagine someone might suspect there exists
a terminal that uses escape codes for first 8 colors, but some other
kind of codes, collected in termcap, for remaining 248 colors. Can
this be considered impossible to accept the patch?
BTW. I've made X04 zle tests more rock-solid, because the debug prints
I added to track the 256-color/zle_highlight issue were slowing down
Zle, and a rare phenomenon (not occurred from the time I've simplified
Zle, disabled the echoing of input text) became very often: Ctrl-D was
appearing too quickly after Ctrl-A. A sleep of 333 ms made the problem
go away, and I think the issue is solved, and Zle tests are quite rock
solid now.
--
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org
[-- Attachment #2: 256-colors-to-use-zle_highlight.diff.txt --]
[-- Type: text/plain, Size: 2540 bytes --]
commit 5dda212b3be3f1f12ad31e3d6543d367f987ee55
Author: Sebastian Gniazdowski <sgniazdowski@gmail.com>
Date: Sat Dec 8 22:42:49 2018 +0100
Instead of using termcap, 256-colours are based on zle_highlight entries
Following code snippet performs the conversion of colour number to the
code to be emitted to terminal (the example shows foreground color
handling):
...
strcpy(colseq_buf, fg_bg_sequences[fg_bg].start);
...
} else if (colour > 7 && colour <= 255) {
ptr += sprintf(ptr, "8;5;%d", colour);
...
diff --git a/Src/prompt.c b/Src/prompt.c
index 568bfc2a9..4a90f5fcf 100644
--- a/Src/prompt.c
+++ b/Src/prompt.c
@@ -1764,7 +1764,9 @@ output_colour(int colour, int fg_bg, int use_tc, int truecol, char *buf)
/* length of hex triplet always 7, don't need sprintf to count */
atrlen += buf ? sprintf(ptr, "#%02x%02x%02x", colour >> 16,
(colour >> 8) & 0xff, colour & 0xff) : 7;
- /* colour should only be > 7 if using termcap but let's be safe */
+ /* colour should only be > 7 if using termcap but let's be safe
+ * update: currently other places in code don't always imply
+ * that colour > 7 => using-termcap */
} else if (use_tc || colour > 7) {
char digbuf[DIGBUFSIZE];
sprintf(digbuf, "%d", colour);
@@ -2020,7 +2022,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 && (colour > 7 || use_termcap)) {
+ if (!def && !use_truecolor && (colour > 255 && use_termcap)) {
/*
* We can if it's available, and either we couldn't get
* the maximum number of colours, or the colour is in range.
@@ -2046,9 +2048,10 @@ set_colour_attribute(zattr atr, int fg_bg, int flags)
}
/*
* Nope, that didn't work.
- * If 0 to 7, assume standard ANSI works, otherwise it won't.
+ * If 0 to 7, assume standard ANSI works, if 8 to 255, assume
+ * standard 256-color escapes works, otherwise it won't.
*/
- if (colour > 7)
+ if (colour > 255)
return;
}
@@ -2067,6 +2070,8 @@ set_colour_attribute(zattr atr, int fg_bg, int flags)
} else if (use_truecolor) {
ptr += sprintf(ptr, "8;2;%d;%d;%d", colour >> 16,
(colour >> 8) & 0xff, colour & 0xff);
+ } else if (colour > 7 && colour <= 255) {
+ ptr += sprintf(ptr, "8;5;%d", colour);
} else
*ptr++ = colour + '0';
strcpy(ptr, fg_bg_sequences[fg_bg].end);
next reply other threads:[~2018-12-08 22:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-08 22:04 Sebastian Gniazdowski [this message]
2018-12-09 19:45 ` Daniel Shahaf
2018-12-11 0:01 ` Sebastian Gniazdowski
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='CAKc7PVBUFSujsBRHi_wbC2zZZp18QdW=1MnrgRzGC+S7T1xEgw@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).