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 a7363c92 for ; Mon, 4 Feb 2019 08:11:37 +0000 (UTC) Received: (qmail 19130 invoked by alias); 4 Feb 2019 08:11:23 -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: 44039 Received: (qmail 11999 invoked by uid 1010); 4 Feb 2019 08:11:23 -0000 X-Qmail-Scanner-Diagnostics: from mail-ot1-f66.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.210.66):SA:0(-2.0/5.0):. Processed in 3.900831 secs); 04 Feb 2019 08:11:23 -0000 X-Envelope-From: sgniazdowski@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=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=X1cdaIRVVVFS/91yzakTfqBnzJBWtGY6j26bWJ84c3I=; b=m0vSXbmI2oljH4wzcQiedxpvRkyXnaVUMeiu0XeLkUx+bPddHuFK2Lg4+s2p3ZDNv9 HjFRihdXEpWnE2v5lIRtzd6OHW1hccjmhvF1TVo8qAY3zr2w/2M3w7AWxBsK0unZxGjL 2txKx6hoP85KRfEeJ+kBZt+i+nbnImqSZ9/V0u4vN/gtGeoKCAwt2bTDPRaY0AOAkPZL jkV/EYx9q2/tQWlIvjo2dinFWZppdcocQhtx7ek9yTNilzdwksqAL9ZUrtJwVs8vqNM9 0L1WI8Kf6RQWm6XvaGNshCbz3cVk1QKwfBC1Js1OBaROdZVdvHduh16yTju/s+SYMJN1 J/fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=X1cdaIRVVVFS/91yzakTfqBnzJBWtGY6j26bWJ84c3I=; b=ewwmj7NZFwrEYDICLZfOqli2TPA8PkDhHel6aVO00Vm7hVUkGoMT/oJxb5xCJHkfhp cZINMTSwfRCl6gCo70kADMaN05OP5jr66HSLTZFvWImAI3bMbSQrC7hZ7IzWsclT5gn6 Xp/IlCiTykA1f4s6dgkEwQjqo539IK17RmBuy6juxrHgqSfWQK3bwJbKSL3yu5j81NDa 3xPysu7vh5a2uH7T7kKUwZSGapb+35+rOONZh2SIxXdYRJYNiAsXqPdoSUr9j2gT931y exAdI+5HmQoonA9SRWXYTPYVPYtTYmtS0rHzN6RFDFesmjh/wp8pMwIDnR2aemYyBMXo xOOw== X-Gm-Message-State: AHQUAuY2T6KobiQ/RHY0O317zQrfSIdnHpi595wPchzdOZc38X2vANa4 1GWvOBlDZamafT0chF2nNtwCXH4Z63uyoa03LmJXW0s+ X-Google-Smtp-Source: AHgI3IZen7hM71xWvM2oSCe/I+6Zj9fSev8rJPJfCd4QlxZV1W2gl2p8k2kOxpy+Nxefuao+TvkRJpHQF5/0ealvLuU= X-Received: by 2002:a9d:3bc7:: with SMTP id k65mr10269875otc.11.1549267876174; Mon, 04 Feb 2019 00:11:16 -0800 (PST) MIME-Version: 1.0 References: <20190203215711.sofrde7s4lb7nttb@Daniels-MacBook-Air.local> <20190204061946.dmygdd7n5c2zoi7d@Daniels-MacBook-Air.local> In-Reply-To: <20190204061946.dmygdd7n5c2zoi7d@Daniels-MacBook-Air.local> From: Sebastian Gniazdowski Date: Mon, 4 Feb 2019 09:11:04 +0100 Message-ID: Subject: Re: [PATCH] Support true colours via termcap interface To: Zsh hackers list Content-Type: text/plain; charset="UTF-8" On Mon, 4 Feb 2019 at 07:20, Daniel Tameling wrote: > > 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. Ahso,,ok, but I don't see the *_TERMCAP code being returned here, could you explain? > > - 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; > > + } > > > > 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. Ahso, ok. > > , 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 Ahso, OK. Let me just point the difference: the second code has two clons after "38:2". BTW., I recomend the following lecture (created by an iTerm hacker) to know more about the termcap-codes deviations: https://terminalguide.netlify.com/attr/fgcol256/ https://terminalguide.netlify.com/attr/fgdirectcolor/ That said: does the new X04 test pass with your patch? -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org