From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: zsh-workers-return-43771-ml=inbox.vuxu.org@zsh.org 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 13f7c72b for ; Tue, 6 Nov 2018 13:38:05 +0000 (UTC) Received: (qmail 5684 invoked by alias); 6 Nov 2018 13:37:51 -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: 43771 Received: (qmail 10946 invoked by uid 1010); 6 Nov 2018 13:37:51 -0000 X-Qmail-Scanner-Diagnostics: from park01.gkg.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(205.235.26.22):SA:0(-1.7/5.0):. Processed in 2.018705 secs); 06 Nov 2018 13:37:51 -0000 X-Envelope-From: SRS0=RZCO=NR=yahoo.co.uk=okiddle@bounces.park01.gkg.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | X-Virus-Scanned: by amavisd-new at gkg.net Authentication-Results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1541511443; bh=ULAliQalJQtqf2lolXRY7u3n++6MsUIl0DdVOfYwutc=; h=From:References:To:Subject:Date:From:Subject; b=jzH4EBLdiXwSyAyKzkuPCAI6BJmhMM/QhTFjPrjwRWVvbrrYoMp30J65H1Y3CnKeovEAldE5CQMjuVnE7i5l5w+Qo1fUIHqSMdv6SfV0yHczssq9guqBv86yP5+offsHKBpIgnpzPu3pxhq8sH+KUlrWZBw8Tz+7UgW8x6VC2zNFfWyubMbCIDxi46cnCctghNRQsdAF52mEsxmU5AhngPZnJIm2XwtjgMr5tkq6UsiWaq7pICnwopmI5FuljDt0JCy6i+8MdJLA9QvdcUPHeKAR24eYxYDYywgKNYsgUQP/wHymq/kF15zqgUzyVQ96l9ROriKu7KYT0aR8GXFrBA== X-YMail-OSG: 32jU8LcVM1lg1N05F.lBeJou7.uikg3OkFeOMlCbDVxaj.OSOrrdVZUlsqvASCv oNbxoa9M3khbeS0Bw2LBBiN2Z5unx81ZdJhGwVUnlsr9VzVC74QGAWuvep14.Jy9mvTYJJg9_h_n MaMGz6ZPwQA_mVM9JjYVB8KiROWDsCN7FdU.xMoombdAD8GNpym7X39AUljy0q8qQR6q6BD6U7_b dofPkfzrJuTRQOpuebR1dnX6RNBqlNMXjAIIu6l6f54sUajtkgvi4Np9d6g25gOik_G758qvjuTL QkKMhQYx.gG_XoPXwla8djGIVtCrL5xaPErjkddlw3c_h_JVxZpD8y5hkYxqbhGzgjlmABKBgsd7 OceE6NZtETLefH1eqdey3ANQgCxdb_5C_N7OrHPWb1L9Ju__jTsNqr_GQ1gnbv_6byNiRmVtzh6q g4Kr3ihkhVnt4PkV.GRNvpqDL24dVr6CrY0NLbjhsvjpCADpI24kXYdezXc2Gh58A9Esu8K9Elkb G0SBHFhtXI6pmndvf.Zt4RiytvTxwFNKxoWJH76k_E1wnt0UkIvad3HksLYRfgaZuCl48J1pXD73 b4u9cH0mHGFhwl4hPG0qqisZJFoNcZ9og3wM4e7pasRLBYdytixqZIXwdQ5x68bX.sE_rK84SUh4 f47Kbt.kJzHcDp.kyjvfaVrw10swC44F_VcbQGbgE2mlUBf3xU7RFeJ22P9wBi_Dj9qaHS677g3i Llt4t55ojSSHi88r13ksME31L1ezRromvDW3EMgpFq_P59RjoDx0WYTsSeEwzciwUkMDTCUjUvkP evdyeVPwTcbelPAv1dDzaoPRwZUFEmT2lUjdo33zkmRqtlLqDTf52NvKyUVhFspXt4OmmPl7oDXq 8T_jiXErsFttPlEVN7AqJxqszWY6Y7tAA_924xOmTaMR04jhLG5MkFbRkrUGVSaf50Tu1_zraKVD EFHEoL_LAGX7Carfttc9E2.vBUBJ1Vv1GH5OPRnuYCImF8QqD2HRhBlqIYmi83RZG6IGKgHlPa8V ePGT_bd5QP6WP_u8- cc: Zsh hackers list In-reply-to: From: Oliver Kiddle References: <58111-1540942908.680582@SXAw.BXd_.-x5N> <14759-1541295720.747208@yAOj.Gon2.-2mF> To: Sebastian Gniazdowski Subject: Re: PATCH: true colour support MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71223.1541511440.1@hydra> Date: Tue, 06 Nov 2018 14:37:20 +0100 Message-ID: <71224-1541511440.931314@XFIZ.XFub.4y-9> Sebastian Gniazdowski wrote: > I'm grepping the patches and cannot find any snippet that decides > whether to use 24-bit escape sequences or zsh/nearcolor module. How > it's decided? The following section of new documentation (in mod_nearcolor.yo) is intended to cover this: +In order to use the tt(zsh/nearcolor) module, it only needs to be +loaded. Thereafter, whenever a colour is specified using a hex triplet, +it will be compared against each of the available colours and the +closest will be selected. On loading, zsh/nearcolor registers a hook function for GETCOLORATTR. After parsing a hex triplet, match_colour() calls: colour = runhookdef(GETCOLORATTR, &color) - 1. runhookdef() returns 0 if there is no registered handler for the hook The following line in match_colour() is: if (colour < 0) { /* no hook function added, try true color (24-bit) */ > You've also written: "No true colour escapes will ever be generated if > you don't specify colours as hex triples anyway. And even if they are, > they should be ignored.".This sounds like: if true-color/near-color > was not enabled, ignore hex-triplet. But I think there is no switch > (e.g. an option) to enable true-color support? You don't need to do anything to enable true colour. It is the default when you specify colours as a hex triplet. With the text you quoted, I was trying to justify this decision by pointing out that there are no backward compatibility concerns - any existing setup that only uses the old forms - %F{blue}, %K{123} etc - will work exactly as before (no true color escape codes are ever generated). But before introducing colours specified as hex triplets in their configuration, users may want to take care to either load zsh/nearcolor or use a terminal that supports true colour. Feel free to suggest improvements to the documentation. Oliver