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 30afe409 for ; Sun, 3 Feb 2019 21:57:32 +0000 (UTC) Received: (qmail 25408 invoked by alias); 3 Feb 2019 21:57:19 -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: 44036 Received: (qmail 24525 invoked by uid 1010); 3 Feb 2019 21:57:19 -0000 X-Qmail-Scanner-Diagnostics: from mail-wm1-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.128.66):SA:0(-2.0/5.0):. Processed in 2.309802 secs); 03 Feb 2019 21:57:19 -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:mime-version :content-disposition; bh=dxn9Ci97508cy+YW/KLb3JDtThlQKF2IZKriKMl1Ql8=; b=AhjJeriJ55U57BNwaRTqxnNQkmqSPfrjyzX0xFNvgO0j/sI4bcDK/PotbizJgtwFxg +2rtDea/FF0i38p+MVrxdA7JlMdYUPyfk6lEwv+XDANBdo9zjbs335RN5BbiXh/+SRpM UK2LLNwtIVrmWA2hgNuziX35bMg2H5q7cgYvk9gQtW5Uw6VboKr2UPUr/fhoLdgiw2aw ZH5dgXHaOt9Hk80+tv1mf01TOCfCZk/9Wt6/GDbkAnnTVBmsc4qI6mm4UYJOpFw2A4Ui 6Y+Vqo6x3gha3mQTblCRF/rnOYneI2bgjZv1vtoKHnNdq6g0woI7mjccJFM/HTo09wjp h4hQ== 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 :mime-version:content-disposition; bh=dxn9Ci97508cy+YW/KLb3JDtThlQKF2IZKriKMl1Ql8=; b=F3QVncr5wxUvdWyEuXMRaTVFELxY878/u8ReFRHiRpAxjsCmUvzw9LjUVDqR9kmkAD FXU0imcY4gezZBa7OvMHP+YJdYKHQKp067anZVMWSigUNB9GiF92FOi2qoB5gcJ/92kh klkjS+getB6WZ/au/tlg2WABufRyp9VJF07Q58S8xEitArqNga3d1e/g2KnYZRKDxNIC m4i0AIsV7FhwLlDVTQQpHcIEa3nXO1aYOsZ/fHPsIZy+CEDXvGd4hRggffRpjyUm20qx oqoTgNqaFNcAPzzPJVnO5SxX+aNbbcLpvJIbVuOV/Hzb6tSg2WirUhM4pZQrct9aCzu3 sOZA== X-Gm-Message-State: AHQUAuY69pCRgo2pn2lgzX/3Hub28SxsATu8RP2NxKLr/jhWWjI9yzDA OcATIpoqDqTiafUcooEftdFDkB0q X-Google-Smtp-Source: AHgI3IbZyMBvbK9QGAzENeR6CLuC69zJDhH8/bqRef1VbH2/kAvKcVHcDfbPOAA1WttferGFeLqx/Q== X-Received: by 2002:a1c:7e56:: with SMTP id z83mr11524895wmc.100.1549231032351; Sun, 03 Feb 2019 13:57:12 -0800 (PST) Date: Sun, 3 Feb 2019 22:57:11 +0100 From: Daniel Tameling To: zsh-workers Subject: [PATCH] Support true colours via termcap interface Message-ID: <20190203215711.sofrde7s4lb7nttb@Daniels-MacBook-Air.local> Mail-Followup-To: zsh-workers MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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. I think previously you could get away with using colours 0-7 when tccolours is less than 8, which now would emit the default text escape sequence. I don't think this change should cause any trouble, but if the old behaviour needs to be preserved, it can be done by changing the corresponding line below to if (colour < 0 || (colour > 7 && colour >= tccolours)) I also let the termcap interface handle the recently implemented true colours, which required only a minimal change as ncurses' terminfo entries use the same encoding as Oliver's implementation. For colours 0-7, however, one has to bypass the termcap interface as the terminfo entries specify for that range the standard ansi colours. I didn't touch the hardcoded escape sequence for true colours because, although there is some dispute on how the escape sequence should look like, it seems that this sequence is recognized by all terminals with true colours support. Please note that the disagreement revolves around whether semicolons or colons should be used as separators, so if the situation changes, the current approach of being able to customize only the start and the end of the escape sequence would need to be extended to let users specify the separator. In summary, the patch enables the following: $ TERM=xterm-direct print -P %F{'#ffcc33'} | cat -v ^[[38:2::255:204:51m $ TERM=xterm-direct print -P %F{16763955} | cat -v ^[[38:2::255:204:51m which is what tput delivers: $ TERM=xterm-direct tput setaf 16763955 | cat -v ^[[38:2::255:204:51m -- Best regards, Daniel diff --git a/Src/prompt.c b/Src/prompt.c index f2b3f161e..589ee7664 100644 --- a/Src/prompt.c +++ b/Src/prompt.c @@ -1652,8 +1652,10 @@ 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; - 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; } @@ -1668,7 +1670,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; } }