From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 869f434a for ; Mon, 4 Feb 2019 06:20:11 +0000 (UTC) Received: (qmail 28968 invoked by alias); 4 Feb 2019 06:19:56 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44038 Received: (qmail 3562 invoked by uid 1010); 4 Feb 2019 06:19:56 -0000 X-Qmail-Scanner-Diagnostics: from mail-wr1-f68.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.100.2/25112. spamassassin: 3.4.2. Clear:RC:0(209.85.221.68):SA:0(-2.0/5.0):. Processed in 4.167197 secs); 04 Feb 2019 06:19:56 -0000 X-Envelope-From: tamelingdaniel@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=UHCoiRwuF1Yy+Zip9hlvRw5lXUWEbpla+08GrXlefNY=; b=Mb44bvTFDeVnn6VZh0q5dY+YeIcGExD4VnqwL9Bp2bA/WxgK7RKneLP36wUGGKE7Z4 fzGZacePLCA/sNvH2cpkLaCistdXjwwmfVGvo6o341D/NmlgYLwEtCoPzfVhfbK+BzVD ftjQUW8NVV/7MFgwfxNujWEMYu6pU1qHy26XWARjaOeNviWLqAQoGh6UzgBQgSKmBn1u +ygLe2IIw0HLqRTlZzE5tRt9qyw47W60hfpFudeUZk7Hfj3Qs7g/Zlr2c/S7uvPnKEpv l1PEwee3aiMEgU6Pj2m0fwFMkPNHvdsSPCQqKCf98aMttPAYtGgVdr7ZFs0l1kAgJcj9 Y+dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to; bh=UHCoiRwuF1Yy+Zip9hlvRw5lXUWEbpla+08GrXlefNY=; b=CGZm8/Lu1bsOHnNAgbL7ZlKZUy0y+qUjalGrcjVC3kk1pbga8nsBPYobr3GyX0zIpa ThqjJz35p7iQZSJNlBjO5yzxgNpFYQcSbNwMlW7s4yL3uNOUdjDAebQ/JCH+w8JOdOgN QrRQTZvBsGwto60GLJ0dDLBWHaqpJzcYjcD8piblwkLaG+4C6ScP309ZO6/feNiftpf8 MKr6ab+Q9an4tg8YMdoQKXTTkfN8tKYvNbd1/EgmFTAarpsJSNG8nZQG4zeUdpsU1R4w 9K3PnZxDpNo2gm+gF1c23GK5B/bd2a2fag9bNSPN31Ahed4yAuswmXL1ZDkKL+jHh+9H IiwQ== X-Gm-Message-State: AHQUAuZISpL6sQ6hPCIcVSW868FPNUfudWe04P2jOiajiJezoNdBqBRz xQPLAwZvF6xgx8truWuag0sKxJHX X-Google-Smtp-Source: AHgI3IYElDOcH37syNt2XyDJy+SRGYFMBO5hjxLNTa5ItWEtT7Tb7swZERsVAh9O84D6OktQnKa67A== X-Received: by 2002:a5d:55c1:: with SMTP id i1mr8578104wrw.149.1549261188129; Sun, 03 Feb 2019 22:19:48 -0800 (PST) Date: Mon, 4 Feb 2019 07:19:46 +0100 From: Daniel Tameling To: zsh-workers@zsh.org Subject: Re: [PATCH] Support true colours via termcap interface Message-ID: <20190204061946.dmygdd7n5c2zoi7d@Daniels-MacBook-Air.local> Mail-Followup-To: zsh-workers@zsh.org References: <20190203215711.sofrde7s4lb7nttb@Daniels-MacBook-Air.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 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