From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,MALFORMED_FREEMAIL,RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 Received: (qmail 14712 invoked from network); 7 Apr 2020 10:58:34 -0000 Received-SPF: pass (primenet.com.au: domain of zsh.org designates 203.24.36.2 as permitted sender) receiver=inbox.vuxu.org; client-ip=203.24.36.2 envelope-from= Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with UTF8ESMTPZ; 7 Apr 2020 10:58:34 -0000 Received: (qmail 4800 invoked by alias); 7 Apr 2020 10:58:22 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 24767 Received: (qmail 4672 invoked by uid 1010); 7 Apr 2020 10:58:22 -0000 X-Qmail-Scanner-Diagnostics: from sonic312-25.consmr.mail.ir2.yahoo.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.2/25772. spamassassin: 3.4.4. Clear:RC:0(77.238.178.96):SA:0(-0.8/5.0):. Processed in 1.89335 secs); 07 Apr 2020 10:58:22 -0000 X-Envelope-From: okiddle@yahoo.co.uk X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.mail.yahoo.com designates 77.238.178.96 as permitted sender) X-YMail-OSG: A5.FbuUVM1lsz4hPO3KgFXjmXaIKpBAaGPLtckvWpSixePKW2y0SnJezEqMiQps CluFj_zsyAQfucxkISWL_mYZdF.LepERGb8lERNw45c2QuHs9DleRMHjLLy1dXPIRvDx3bATjpEo lBtpnqcfVLAgFMXXMwsLt_jCJgJY6aW_ih5Hrf_EyX8V5hvkZRzulG9gJw9RdBP9juXvAaUdsrDo c2Tg23R.4dthboARbDik08a0VpgdxqAZX3p5t2wMr9Z7Zxf1xUghdBHUKlj9nyb9.oy_6BSG71hG NFWCB607ijBK4h7Ic_QLEvVpzsYag5mJ3Mu1pLt.Q0Kv2SJMOTEvQAQPPJ0usKap_Y3g6y2glk1b 7umEl9hgnfQoBOyPySAtlkA8mIN51OQ8.a7nIBxTtTq9tzY_vxlgjp_lkTD5IwXbWE0qThQ5ATIU mp9i34AM3Ib_pIqPo1n3VxBpTZwUNEehuUsVq2rdVSCWNO7kKMm3bOHaV930V_q.4YhVRF5_JHRl .mVgSwG_S5lm2Q0YfQHMheWIJk1lRDiGKoQzO7AjB9nynxfUq8WyO54MpopocGJiFFb7HeGsoINh jj3p5lHJFCU.Cey.XCkIHNQNdS4BGGtEUrUp44v3TmB80XDQ1c_f4piWJDIqgZc5ZUlwEVlL5G1j x4TSJoINCwDoX25gscvHV3Vj40GNL1Qht3IYwHwPPcWvij.DUjElGb2gHXYdOeFHK2LfUdhwkr9v yPL6nzaDz3Y88jKXOVypehSDRRfr5gcQfrKwfZtZBCish9x9nF2vZyVfq4alYn1jNv27t3J7QQhf 7FXmz6cYLROExnevfw5FmODEsIcKVXwXYXm7VDBuQ4z0C8vkTq.GKNFEwAVhRfD5QjA4MPy_FkV8 _RTqVaGXexW9o3JOS5Xep_xt9MTJ1fgmmor0k4h1PJmkbWl9A2eedJMv_RGRnR8.CciBSm7ke90W dUkfzGKejOliC5f_l1gDFql0ASdhuuA1YAXDVk4X.AH0i.RcivZEeRKlWMdroYjviEt9hz4X3_H9 8x07jnYuUc6VqPqX0C0yZBn8Iw69jaz0CT4QAwSMPHF9vbBTkMctAUEoKPgp6oNEuV1TNFeXwnzP oLZpZtgrIT1nZWkbAd_eI4STnTKRhfpmpDvrWrbfq5mYuxw0UtLdPVJ9gyhFmjj9mG9MfUTLGtAN RjhzZonhouCkEMX9aSMmF8_l..j_00r9kScIq4sRmTsQDadlNQvU3wpy1q4Kc3pH0rgH5xLrThtQ 8V0YHwhPivRWa5CcIxfY31eHy2XPBy_Wpkl.t1JbgtNZUH2EYIeBg789t89RMbY6fk03CoTTLC44 3vzOhr2kfTkylAWn_xe1fWWH7oaFfYduZdWaNbWHf5g7c4MPE1Eput_RWLjOX9dFhv_GKS_fqvGJ N2p2a1AtUQbQ- cc: zsh-users@zsh.org In-reply-to: From: Oliver Kiddle References: To: Thayne Subject: Re: Using 8bit colors in prompt expansion on a terminal with 24bit color support MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <93762.1586257060.1@hydra> Date: Tue, 07 Apr 2020 12:57:40 +0200 Message-ID: <93763-1586257060.854308@Xadh.RrV-.d5CK> X-Mailer: WebService/1.1.15620 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Thayne wrote: > I recently tried out powerlevel10k, but ran into something weird. The > classic theme had blue backgrounds, where it was supposed to have gray > backgrounds. After some investigation I discovered it was because the > `%K` expansion just passes the value through to the setab terminfo > format, which in the case of "direct" terminfo entries > (alacritty-direct in my case, but I think it would be the same with > xterm-direct) assumes it is an RGB value if it is greater than 8. > Apparently this is intentional behaviour > (https://lists.gnu.org/archive/html/bug-ncurses/2019-03/msg00009.html) > for terminfo. I'm not familiar with "direct" terminfo entries and haven't found much by way of useful documentation. Does selecting this provide any particular benefit? Or was it a default setting with alacritty? Based on a bit of probing, it appears to be meant for explicitly true-colour terminals with the 256-colour palette being dropped. $terminfo[colors] reports 32767 which is rather less than a full 24-bit range but there may be other reasons behind that value. With %F, %K etc, zsh ends up only filling in the blue part of a sequence that has separate red, green, blue components. So it would seem there is no numbered palette. Many prompt themes and other terminal programmes assume the use of the common 256-colour palette so it is no surprise that they should break. > Is it expected that zsh's prompt expansion for colors behaves this > way?If so, maybe the documentation on it should be more clear that it > is the users responsibility to make sure that you use 24bit colors > (with hex) rather than 8bit colors if the terminal expects it (by > checking for the RGB property in terminfo). Or should zsh map the 8bit > color to the corresponding 24bit color? It has always been the case that colours specified with %F, %K etc were passed through fairly directly and it was left to the user to adapt according to how many colours their terminal supports. So when moving between 88 and 256 colour terminals, the same values can have quite different effects. As far as zsh is concerned, the old values were not 8bit values but terminal-specific values. That aside, and given how 256-colours is far more entrenched than 65 or 88 ever were, mapping colours may be the best approach. That assumes we can detect the situation reliably. Is this RGB property documented? I'm not sure how simple it is to check given that zsh seems to mostly use termcap sequences. Oliver