From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1480 invoked from network); 23 Jul 2020 04:46:59 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 23 Jul 2020 04:46:59 -0000 Received: (qmail 3833 invoked by alias); 23 Jul 2020 04:46:50 -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: Sender: zsh-users@zsh.org X-Seq: 25004 Received: (qmail 8054 invoked by uid 1010); 23 Jul 2020 04:46:50 -0000 X-Qmail-Scanner-Diagnostics: from mail-yb1-f195.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25877. spamassassin: 3.4.4. Clear:RC:0(209.85.219.195):SA:0(-2.0/5.0):. Processed in 1.320509 secs); 23 Jul 2020 04:46:50 -0000 X-Envelope-From: aaronjensen@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.219.195 as permitted sender) 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:cc; bh=05NkNJkOkyRtoHLsx84g/FMDP6fYiqP097XoCJBMQSE=; b=AV/5lwQhX+NCGtuvVomHKCd+WaLoM8YkU7/ghrFAkD44yQp3FJK2fzF+ixr5Oi5R7j 9XLJAPUDR2cRZ178wiO+hPM5jsmOgOWUawaMn+yLMS0Bq+34H5zM+1oNu41fnj2D1MO0 Y6rweAfuHUZc/Ewnw7JJKJS5a0DqJdhTF/+mZS38grmv7C1V7ZaeOKGCCGETU7lqH0SC nNTFZb0ZnMcocGvKqtvCZ0+V4IweBV/IRxtvfNyFbDE/xTQSe1RH36AaK+JFoDGlToZa xtEiyHv4bqk4F50k9nDYIb6eYpQVrnafcayHFtWfyJfPlPdhm7gbqqxw8KeoYW1nm0qp LPXg== X-Gm-Message-State: AOAM530S4kdwaN9DkFcBHn+Zs7P/a/+i/BmLt73xyo9/upOeY387DnDZ HbmJxUqCi1T2WYmcV9j/CGWmaKiDeMnB6DQNCmNwodSH X-Google-Smtp-Source: ABdhPJys1iuaew3WDkGEEKReu7wbjA3Zv9UJuyAeVA8UyBaeZ4ouTQSYyqJGLaZnSn6IQUN9v6nJYhz8qnvsEUyynjI= X-Received: by 2002:a25:bfc5:: with SMTP id q5mr4407927ybm.475.1595479575139; Wed, 22 Jul 2020 21:46:15 -0700 (PDT) MIME-Version: 1.0 References: <1742-1595405609.146071@5EJy.NK4K.Onqo> In-Reply-To: <1742-1595405609.146071@5EJy.NK4K.Onqo> From: Aaron Jensen Date: Wed, 22 Jul 2020 21:46:04 -0700 Message-ID: Subject: Re: xterm-direct and zsh To: Oliver Kiddle Cc: zsh-users@zsh.org, Daniel Tameling Content-Type: text/plain; charset="UTF-8" On Wed, Jul 22, 2020 at 1:13 AM Oliver Kiddle wrote: > > "Aaron Jensen" wrote: > > I'm trying to use TERM=xterm-direct with zsh and finding that zle doesn't attempt to render things in 256 color, instead falling back to 8 color. > > With TERM=xterm-direct, terminfo is reporting 16777216 (2^24) colours rather > than 256. So what's to say that a palette of specifically size 256 is > supported? Fair enough, I just made the (incorrect) assumption that since 256 < 16M, it should be acceptable, but I can see why there's no guarantee there. I'm sure in practice that terminal emulators that support 24-bit will also support 256 color and it's unfortunate that there's not a way to specify both. > Are you able to point to some documentation for xterm-direct and what it > is supposed to achieve? It appears to exist to explicitly advertise > support for 24-bit colour in the terminal. Many terminals have support > but in the absence of a way to detect it, we've had to leave things up > to the user. > > A side-effect of this is that it is no longer advertising support for a > 256 color palette. It'd be good to know if that palette can be relied > upon when 2^24 are reported. Even if it can, I'm not sure whether that > is wise or is missing the point. In the past various smaller sizes were > also common (rxvt-unicode is still often built with 88). Right, I think in my instance since there are only a couple apps that use 24 bit color that I care about, and there exist workarounds to advertise to them that it is available, I will let zsh continue to think that it's xterm-256color. > > I found this patch, but it does not appear to be applied: https://inbox.vuxu.org/zsh-workers/20190207203257.7sfyvpooegdjgice@Daniels-MacBook-Air.local/ > > > > Am I missing something or does zsh not properly support xterm-direct yet? I can't see where or why that patch never got merged. > > It's a patch that needs significant review time. There's a lack of > documentation in ncurses so it would likely involve either guesswork > or trying to make sense of discussion from ncurses development. Then > understanding how things might react with other termcap/terminfo > implementations and terminal definitions given that it is potentially > adding assumptions to the code. The discussion with Sebastian somewhat > buried the original point of the change. It does 4 separate things > and change (b) is arguably pointless if the defacto standard works > everywhere. I think at the time, I only had time to take a glance once > that discussion was ended. I've added a note to my long TODO list and > copied in the author of the patch. Much appreciated, thank you for doing that. > For the moment at least, I don't think any terminals are defaulting to > xterm-direct and most systems I use have no terminal definition for it. > So it requires people to be manually setting TERM to xterm-direct to > trip over the issues. Here I am, one who has tripped :) I was drawn in by the idea of removing hacks, but I see that the world isn't quite ready for 24-bit terminals without hacks. Thanks, Aaron