Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
[PATCH] Make 256 color codes be based on zle_highlight array, not on termcap
- X-seq: zsh-workers 43875
- From: Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>
- To: Zsh hackers list <zsh-workers@xxxxxxx>
- Subject: [PATCH] Make 256 color codes be based on zle_highlight array, not on termcap
- Date: Sat, 8 Dec 2018 23:04:33 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FgDrcUINpYJcJkaXVIUOjXW9HotcT/6rVnCVkMHnFI4=; b=kKK0WSYKs9ABlUZmsOnbmLWZF4RZahvxRx/BSMw4YExmYreFElxDrmWtm2WMc33H8+ AlVqmTMiuBL4O8UOHH3BJ7x5SqUEx5TT41l56cJWnz6+WeCH9vE5jWg8oYqEn7rUSo8P KE+llO1sMZ+5+yaY83QOwsbAo82od1X752nqQ4gCJhND+J2h/XCxgFMs2uhAzFW3rxBv rxiizMwctW1d+RdxymCfS8u97RU5diWoPwXy7piZjiyhbby+dSG+I/USeUZK6BXJSrt6 Qv/+H9ttsMbkEHs1HWGOMvvXNSAk07tGuQBxMdJT0rCPM0HKT7a3wp2Dl03I0cXd2I/n y9SA==
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
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
commit 5dda212b3be3f1f12ad31e3d6543d367f987ee55
Author: Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>
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);
Messages sorted by:
Reverse Date,
Date,
Thread,
Author