From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from zero.zsh.org (zero.zsh.org [IPv6:2a02:898:31:0:48:4558:7a:7368]) by inbox.vuxu.org (Postfix) with ESMTP id 175A92407F for ; Mon, 4 Mar 2024 23:51:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Message-ID:Date: Content-Transfer-Encoding:Content-ID:Content-Type:MIME-Version:Subject:To: References:From:In-reply-to:cc:Reply-To:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=61ney2AubvMJFS51UoRc10gD4uyXQdH3pAswORRNi7w=; b=sDdA97AH3G0GprUjVoRZ81aBaJ sExQLlgU6tU0icNtp/f+iiSqMcUd4L5dlHkoO8fWIJgwiz5/qMBHokTodvAhuf+gT09D9VPLFRcar 6nCLyGWOtwbhSpsemGmSqykGB71/rBCH7iqHTZLKK+Kw8UcSIJNzUqibF2/m2lZJ0jN8eHIXOKFeY Lyi5oTcGF4DvgsHrz0gUE5yOoNPljK+td0xIZeWgl8l9cJRCkxPS55aTrd5OkmC8sC1o9Uv25dGcl s6DAUfXFP6Glp7HlMw64VidlayojjCofw2F31B4x1RKrxwECxtSXHv0ueHj1xuhG0XpQFh2whu9i/ pAOVv2Lw==; Received: by zero.zsh.org with local id 1rhH9X-000OmA-H4; Mon, 04 Mar 2024 22:51:23 +0000 Received: by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1rhH8j-000OQT-GU; Mon, 04 Mar 2024 22:50:33 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.97.1) (envelope-from ) id 1rhH8i-00000000LdG-1eQE; Mon, 04 Mar 2024 23:50:32 +0100 cc: devs In-reply-to: From: Oliver Kiddle References: To: linuxtechguy@gmail.com Subject: Re: What appears to be inconsistent results from ${(%):-%F{${subscript}} MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <83156.1709592632.1@hydra> Content-Transfer-Encoding: 8bit Date: Mon, 04 Mar 2024 23:50:32 +0100 Message-ID: <83157-1709592632.390382@nUgp.Wjpi.Cm2K> X-Seq: 52672 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: Jim wrote: > Output for the  following function will help visualize what I believe to be > inconsistencies of the output of ${(%):-%F{${subscript}}. The escape sequences generated for %F, %K, etc come from the system termcap database. So the output produced by your function will vary for different systems and terminals. This makes it difficult to understand what it is you regard to be inconsistent. For some terminals, the colours 0 - 255 result in consistent escape sequences running from \e[38;5;0m through to \e[38;5;255m Check what the AF termcap (or setab terminfo) entry is for your terminal: od -a <<<$termcap[AF] or some other terminal: TERM=foot zsh -c 'od -a <<<$termcap[AF]' This string (which is processed by tparm()) may contain conditionals and amounts to a stack based byte-code. It is not uncommon that this interface will generate \e[32m for colour 2 (green), \e[92m for colour 10 (bright green) but \e[38;5;82m for colour 82. Perhaps this is what you are seeing as inconsistent. The termcap/terminfo interface only accepts a single number as the parameter for this entry. > To my original point > > 1)  the color names grey and gray do not output black but output the default grey/gray is not one of the eight original colours supported by a terminal that supports eight colours. Terminals that support 16 colours added 8 bright variants. bright-black and bright-white is fairly meaningless so in practice, "white" was often somewhat off-white and bright-black is what might be better termed "grey". > 2) bright color names are not converted but output the default color >     Should bright color names be added to the code? >   As you can see in 3) the code for bright colors is there Unrecognised values select the default color. My own opinion is that it would be better not to try to recognise more colour names because it'd just lead to more complaints about names not matching colours. Also, grey has two valid spellings and "bright" amounts to technical terminology that is only meaningful with the context of historical terminal colours. TERM=linux may support colours 0-15 but not all terminals do. > 3) using decimal numbers(0-255) >     0 - 15  uses 30-27 and 90-97(bright) instead of using the colors defined >    by the terminal >   NOTE: 0-15 are defined even for TERM=linux >   16-255 uses the colors defined by the terminal >   Is there a reason why it doesn't use the terminal colors for 0-15? I'm suspecting from this last sentence that, in the interests of making a wider range of colours available, your terminal is producing different colours for different forms. So perhaps \e[92m is a bright green and \e[38;5;10m is something else. For the termcap interface, there can only be one colour 10. Hard coding escape sequences in zsh should be avoided if at all possible. If you really want a wide-choice of colours, most newer graphical terminals support true-colour. (Though some of them fake it in the interests of keeping memory usage for the scroll-back buffer down. And others just consume lots...) Oliver