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 8651e8d7 for ; Mon, 10 Dec 2018 03:01:59 +0000 (UTC) Received: (qmail 25490 invoked by alias); 10 Dec 2018 03:01:43 -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: 43884 Received: (qmail 19974 invoked by uid 1010); 10 Dec 2018 03:01:43 -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.100.2/25112. spamassassin: 3.4.2. Clear:RC:0(205.235.26.22):SA:0(-1.8/5.0):. Processed in 3.992114 secs); 10 Dec 2018 03:01:43 -0000 X-Envelope-From: SRS0=nV3M=OT=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=1544410470; bh=S6eKZU2ISnjLSFOYyW6gAJu19oFKZ8VPizW38+yVBJk=; h=From:References:To:Subject:Date:From:Subject; b=EsqN0szXrKrtUd6Aj3LcelBxR9qTvblaMj73JP/ul7US/xbvwXIj0hd+7FOUTlSlCcLnscfNtj1HboG+e/N28JpzmVJW8qebyBuZ8hg8Ie/YESrltBU4wA/PeVQwdeHF3rR6kg7Qy5ZNTRA/fbJKZdOoq9ozi7BM1Kmk6t52JhMuAMdBUD3nGjTSbvnshzq0jBhLnJwGwTf2NCFXFQIoxetNDTCAkkliKUBRcbxasgyPvrD70kP+e2ozINdvr1l2fJyyiA7Q/yA5t4srrhg9b7hnJOJo9qB0FxFy1uyVv/iNL8Rh6Gu0ZBdeXWKA4xtV9ytTLs2Jc3GgSVcxAvqkVA== X-YMail-OSG: aIKxS4IVM1lh4UPAZW2OEumHdbKM8wedJ8jyxzuHOheb5JjIil_5OG1T_UfxRgL aFWOOvkUoxNuk3wAbIgsw5PFSusf9BZjFfnadGAuQ1iiIMFn5tmR22CfmfatkiCNU2nS.BBCEH1z D3QOyIIhJ8Bk2FDzHhbq2V0LQj9J3ae5pKxnv8X9EM5E29fWKPikPx45HId0k5dRk9qNcp19LzvQ SBagZT3jZuEDVn7I4pJNtxz64gH2LCKlbbizjvZF_fqQ.8ZtDARGN8xNQnj.c6rZjF5lLK1hDh4A 6lKA8FX00CmQKYWTCxZ0160LlQKHMMSYDoSPJxHG9_uHR6KAhTttVCLXvCxb.y5mWRw1ofspnpl4 h92LqjkuAvc_hhBiXC4sgEyQHSN3TyikbnHsNVH3r4KSVqMktj.7A_5ohv9dTajSrYkyHadDYzmT WwEmZZf8GHANcTQg2PX8NLGEKpqQEsEcvyMUmqd4RLbKBWTbd1LoTNdYKfkzxdIUV2ilbbAOZtNM j4XWq1a9.pDE1zMLyhh1KvI1Xhbm0KlYflf9ES7h8TZG.hw5JVhniwX4O7g0f2HRFDN4Fw1UqYLk y2JRoNaPrvImb22gOUvsXTmfZX6dCgr81YMCKvoE_7dSM.3lmNHgl9LpS2BRj9a21FYIUDRqtx2c GKWiOLYipP.gTpbJjiIjg8754KF4RCKRIeMJrKDWjzxG8c5Uj3QVNhxawpbmYCJbdnWqMejVEfXR fKGdIz99Ho.3u1s3qhmhN66XubkVcXJc.E7d5OOnjYCyldSTqzrZh_BZaXmx64VBizCmojq1CFt1 TkBUz9BHpcdXJVEBMow3HJwaX7lqRCnrIJ.8JTGYIRHvL8FdLTCHRztaydFQAAbeie1TcXEHXRC0 1SQkmSg3Y1Vn8ZmkuKkR8rG7svyoMxZxVdNBcwpds4f147nhruLfLj7vFO3137bds4DdpFh4NC2v 3kxeRNrB4IOXV3UzfYg60lbQUaCIzu4m.XYy4Nk8iu1Voso2Zh.aSsqm9nqX6_MqRLsbB.vB3j2D E4bV2.d8EJlaLPazLP.wvu2gkjlSWCxz8UbWMknogIHbUdSfyMeQCDzLqGs91ZTycZsHGFRuL5zE - cc: Zsh hackers list In-reply-to: From: Oliver Kiddle References: <2362-1541646201.813952@nGIL.zWP_.YhaK> <20626-1541726901.821000@xGvJ.shtD.SkCN> <31159-1543080743.164776@h8df.-SiL.hblq> To: Sebastian Gniazdowski Subject: Re: highlight test cases (was Re: [BUG?] If true-color is used, overlapping colors do not work) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <34191.1544410467.1@hydra> Date: Mon, 10 Dec 2018 03:54:27 +0100 Message-ID: <34192-1544410467.201850@fxvz.2eq1.BJLG> On 30 Nov, Sebastian Gniazdowski wrote: > The output doesn't follow zsh_highlight replacements for start-code > and end-code and still emits raw codes. > > Could this be fixed? That was intentional. As I stated in 43759 which was the message including the true color patch: | The actual escape sequences appear to be quite standard and are, for | now, hard coded. We should probably support some zle_highlight fields | similar to fg_start_code to allow them to be configured but I'm unsure | of what exact form that should take. It may not be good enough to overload "fg_start_code" because the escape sequences might vary for 16, 256 or true colours. Quite why termcap isn't used for the first 16 colours, I couldn't say but I'd have thought it is always better to be using termcap if possible - contrary to your change in 43875. Apart from that concern about overloading the existing fields, I don't object to using zle_highlight as an override or fallback for termcap if that's somehow useful. In the case of true colour, start and end code may not be enough to encapsulate all the relevant details. The sequence I used has decimal numbers separated by semi-colons but judging from https://iterm2.com/documentation-escape-codes.html there's a macOS terminal emulator that may want hex triplets. This is what I was referring to when saying I was unsure what form the zle_highlight fields should take. The current hard coded escape sequences work for everything I've tried. Oliver