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=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16463 invoked from network); 31 Mar 2021 08:27:15 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 31 Mar 2021 08:27:15 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1617179235; b=uyl7u6vEkL0XxjFsFSHWubwAi4OmR0q0e02Yov7/Sra2UPiAZ/WOveIreyHBtv4RFPstsUAv7w Xls++u+l0o2pZL0umHrZZzvasZ8QaiAqFrS+TQc1iCYei4Bgx1j85naT9rQMPwwsL/STBeHJcs xT2XfFYj9JzA1ulLXONOEcNf769rHZ9zm2+qTR91x3CDgfKRn6GGh39aC0Jmft6a5sGeL6iD2d g7nka8qLNgSYi2sERuLm5FrLNYQyMhXnmdPP7bSeHAn7LlaDXeZY4uJOj20pC/tLt4C6eXJwGm xG2vSWoAhSlPp1WC9OY0IO28otDrvMMcLDRW8g08TiK76g==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-lj1-f169.google.com) smtp.remote-ip=209.85.208.169; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20200801; t=1617179235; bh=RQqwSZJx0HQ+5iWXCys1V/ESdyGI1rsa/wHOwOvUa3I=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=kA0J9E/A60mCivXRQZRq4SMtekshotgb0XdmOL3NyXoq/VlNh3xm528U3g3TBeoGOFvlcLPUQw tJm/FukAahSkEmfnXAgAe60R8y08cGwpM0mGhUJWtcFpiThBndDM7qmH2DhY1up+rs6BG/NSIH YxT9Ey8fh2C0hFNEuf0h6YfcR+x4u5Lbd7ESadQDXDE2L1RJP+ZePPct1RA+BZvwu8U0B2H8cI zHAZ/FqbkabGS4huhhxZi3LsUnQXrxa4t31STEqu1bNIGFBJzr04Ekz/12a2Zk6/mayYWyUDLL CWHjzouV/CGXxNQsZfydqJ4qW5mUi3FoXVKpQPslmL6cFQ==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:To:Subject:Message-ID: Date:From:In-Reply-To:References:MIME-Version:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=TfiknQDdIh4vLIM8/towrbFbie0sTxFfAIj5uBODI0Y=; b=ywzr9uc2vYhWAk7IOO/H5hmWDB dteU4xjE72tyxavgm3HTCEEXLMNYwL7mAHcimLVqwMPcIfvfnBiCWMtNrOttoa2hOVs75lG4T9L5O gI46YatGpal6PHMdEWwFCsyVSSPnXUBccp9ByD8532yBFDdb3S54vLU5xOsaabLgCppGmj2ge4zFM 7l0U46NJv/GCXAVJpQx9GzxfufYfQJDOs1p05ZAMSUfxjT0T3do1Go/Ww6VeIQoWf6OREXSVjKEee T4uWWXMV8Ukw8oA41D1Ynr1Xs8gXBDkvcjlNl9+K2FJtaIEYw1DNOvZXp+7c82kEBCOl5Ozu2LrN0 6RvR6FXA==; Received: from authenticated user by zero.zsh.org with local id 1lRWC2-000EPJ-Ni; Wed, 31 Mar 2021 08:27:14 +0000 Authentication-Results: zsh.org; iprev=pass (mail-lj1-f169.google.com) smtp.remote-ip=209.85.208.169; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-lj1-f169.google.com ([209.85.208.169]:45784) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1lRWBo-000EG0-6d; Wed, 31 Mar 2021 08:27:02 +0000 Received: by mail-lj1-f169.google.com with SMTP id z8so22780466ljm.12 for ; Wed, 31 Mar 2021 01:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=TfiknQDdIh4vLIM8/towrbFbie0sTxFfAIj5uBODI0Y=; b=UGtkL/PNHrAeUVSHdXkJ4SH6S+1Cot6V3k2XbT76y10zmp53vFGCMQ6ATqGFfTxlWG Ms6D7Hsv8m/H4WmvByoh44HxmjI4eLQsX7UqPVtCHO0btntRBSGi6XTAZdXOvQJ44cK2 GeeBH9QaWt0RVU9VVAFU0EkLsweirTIl6H7prbWSDPxlfLrhGSwm8FhJG62TNjpo6hqn 4VONu9RdCAthpzlb4uI3h8ah0VpD79Ujb/ogTpBuMyPG+qrt9mt87iIxN1hfCJ9ggXT8 QrQQ+vz/9XhDqgRnzh+YsXUkRUK3bbT7or4ix4Q+asVzwRul8U3jX3FPzpKBm9KMU2Fs CKfA== 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; bh=TfiknQDdIh4vLIM8/towrbFbie0sTxFfAIj5uBODI0Y=; b=Rs/LFbP9hYOCVwrY+lIy36dksyfMuLEFX/B8aYY3yzRq7HRHIk+kDNqyemWZ86a3VZ +10e5RQLtvFrXfE5YSSWP3IJd/mHJ+sOMLb1VdpVdQcpAlryJjU2+BKVzL/fGvCC5nXB vfgk2Fh9ukshl8VyUz6aQTK+w5/dcm2stHy8UUBdKpMLRGF3L4brbu2e9vxnvHuNGtpz /F+YwRKsWwJLrjmnJavGeJ1lOGhcprDU5nDkL9z70xTKBhnc6MMECuiL72tMACvhloYE vqfXQv5cS0emlwwGQLo8IdQGRnXY14xHBF7d+TWoTSpjWXrQF/llnA+PjdO2BRbBBsi7 ToUQ== X-Gm-Message-State: AOAM533rFpgWzwH9uUUT4pISQYTy3nWq8KxiG1+sLdc7WGFNieYWZsF0 Qi/Rvkr2XKcRBU5lpwOdASu/UvFeZIWlRFwAnTVy/aP22Lk= X-Google-Smtp-Source: ABdhPJzXVGQ7FocYsRWP5Y/am+DqVwoc8qg/A5gMocJ3eBotzMQC8ULu3wm8MjJ8XVAYQAVJd2tsox6lQ/l36rWM9Uw= X-Received: by 2002:a2e:a60a:: with SMTP id v10mr1405217ljp.267.1617179219103; Wed, 31 Mar 2021 01:26:59 -0700 (PDT) MIME-Version: 1.0 References: <20201014204621.4cf5b2b0@tarpaulin.shahaf.local2> In-Reply-To: From: Marlon Richert Date: Wed, 31 Mar 2021 11:26:22 +0300 Message-ID: Subject: Re: region_highlight converts `fg=default` to `none`, which is not the same To: Zsh hackers list Content-Type: multipart/mixed; boundary="000000000000e544d205bed0e071" X-Seq: 48345 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: Archived-At: --000000000000e544d205bed0e071 Content-Type: text/plain; charset="UTF-8" And here's another patch (attached) of Roman's that still needs review. On Thu, Oct 15, 2020 at 10:37 AM Roman Perepelitsa wrote: > I haven't tried reproducing the problem with z-sy-h. Instead, I've > used the following code from `zsh -f`: > > zle-line-pre-redraw() { > region_highlight=('0 5 fg=1' '1 2 fg=default' '3 4 none') > } > zle -N zle-line-pre-redraw > > If you type "12345", odd and only odd numbers are supposed to be red. > The actual behavior is that all numbers are red. > > I now took a look at how highlighting is applied (function zrefresh in > Src/Zle/zle_refresh.c), then read the docs again, and I think there is > a problem. If the same character is affected by two highlight > specifications, how should it be highlighted? For example, if the > first spec sets fg=1 and the second sets bg=2, how should the > character be highlighted? What about fg=1 plus underline? Or underline > plus fg=1? > > I could imagine two simple merging strategies: > > 1. All attributes are merged, so fg=1 + bg=2 + underline would result > in underlined red text on green background. > 2. The second highlight completely overrides the first. fg=1 + bg=2 + > underline results in underlined text with the default color and no > background. > > The meaning of "none" naturally follows from the choice of merging > strategy. In the first case region highlight with "none" spec has no > effect (X + none => X). In the second case such a region is displayed > without any highlighting (X + none => no highlighting). > > The actual code does something else. If a spec has fg or bg with any > value other than "default", then the spec completely overrides the > previous spec. Otherwise the spec is merged with the previous spec > with one exception: fg=default and bg=default have no effect (fg=1 + > fg=default,underline => fg=1,underline). > > Note: "special" highlight is merged with a different algorithm. All > other highlights, including "region", "isearch" and "paste", are > merged the same way as the elements of region_highlights. > > A few examples of what the current code does: > > - fg=1 + bg=2 => bg=2 > * the second spec completely overrides the first > - fg=1 + underline => fg=1,underline > * specs are merged > - underline + fg=1 => fg=1 > * the second spec completely overrides the first > - fg=1 + none => fg=1 > * specs are merged > - fg=1 + fg=default,underline => fg=1,underline > * specs are merged except that fg=default has no effect > > This doesn't look ideal. So, how can we fix it? > > "The second highlight completely overrides the first" will change the > meaning of "none" from "ignore this spec completely" to "display text > with no highlighting". For example, if you set > zle_highlight=(special:none), special characters will have no > highlighting whatsoever, while currently they would get highlighted by > region_highlight. > > "All attributes are merged" makes it impossible to disable underline, > bold, etc. We have fg=default and bg=default to disable colors but > there is no equivalent syntax for disabling underline. > > I think there is one change to the current algorithm that would be an > improvement and is relatively safe to do -- make fg=default and > bg=default work similarly to fg=1 and bg=1 as far as merging goes. > Since fg=1 in a spec causes a complete override (disabling underline, > bold, etc.), fg=default should also do that. Patch attached (only for > zrefresh; singlerefresh should be updated similarly). With this patch, > if a spec has fg or bg, then it completely overrides the previous > spec; otherwise the spec is merged with the previous spec. > > From the examples above, only the following works differently with the > provided patch: fg=1 + fg=default,underline used to produce > fg=1,underline but now it gives just underline without foreground > color. > > P.S. > singlerefresh() doesn't use default_atr_on and thus > zle_highlight=(default:fg=1) has no effect if SINGLE_LINE_ZLE is set. > Is this intended? --000000000000e544d205bed0e071 Content-Type: text/plain; charset="US-ASCII"; name="highlight-patch.txt" Content-Disposition: attachment; filename="highlight-patch.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kgaieylq0 ZGlmZiAtLWdpdCBhL1NyYy9abGUvemxlX3JlZnJlc2guYyBiL1NyYy9abGUvemxlX3JlZnJlc2gu YwppbmRleCBkOWQ5NTAzZTIuLjFiMjQ2MTkxZiAxMDA2NDQKLS0tIGEvU3JjL1psZS96bGVfcmVm cmVzaC5jCisrKyBiL1NyYy9abGUvemxlX3JlZnJlc2guYwpAQCAtMTI3OCwyNyArMTI3OCwyMiBA QCB6cmVmcmVzaCh2b2lkKQogCQlvZmZzZXQgPSBwcmVkaXNwbGF5bGVuOyAvKiBpbmNyZW1lbnQg b3ZlciBpdCAqLwogCSAgICBpZiAocmhwLT5zdGFydCArIG9mZnNldCA8PSB0bXBwb3MgJiYKIAkJ dG1wcG9zIDwgcmhwLT5lbmQgKyBvZmZzZXQpIHsKLQkJaWYgKHJocC0+YXRyICYgKFRYVEZHQ09M T1VSfFRYVEJHQ09MT1VSKSkgewotCQkgICAgLyogb3ZlcnJpZGUgY29sb3VyIHdpdGggbGF0ZXIg ZW50cnkgKi8KLQkJICAgIGJhc2VfYXRyX29uID0gKGJhc2VfYXRyX29uICYgflRYVF9BVFRSX09O X1ZBTFVFU19NQVNLKSB8Ci0JCQlyaHAtPmF0cjsKLQkJfSBlbHNlIHsKLQkJICAgIC8qIG5vIGNv bG91ciBzZXQgeWV0ICovCisJCWlmIChyaHAtPmF0ciAmIChUWFRGR0NPTE9VUnxUWFROT0ZHQ09M T1VSfFRYVEJHQ09MT1VSfFRYVE5PQkdDT0xPVVIpKQorCQkgICAgYmFzZV9hdHJfb24gPSByaHAt PmF0cjsKKwkJZWxzZQogCQkgICAgYmFzZV9hdHJfb24gfD0gcmhwLT5hdHI7Ci0JCX0KIAkJaWYg KHRtcHBvcyA9PSByaHAtPmVuZCArIG9mZnNldCAtIDEgfHwKIAkJICAgIHRtcHBvcyA9PSB0bXBs bCAtIDEpCiAJCSAgICBiYXNlX2F0cl9vZmYgfD0gVFhUX0FUVFJfT0ZGX0ZST01fT04ocmhwLT5h dHIpOwogCSAgICB9CiAJfQotCWlmIChzcGVjaWFsX2F0cl9vbiAmIChUWFRGR0NPTE9VUnxUWFRC R0NPTE9VUikpIHsKLQkgICAgLyoga2VlcCBjb2xvdXJzIGZyb20gc3BlY2lhbCBhdHRyaWJ1dGVz ICovCi0JICAgIGFsbF9hdHJfb24gPSBzcGVjaWFsX2F0cl9vbiB8Ci0JCShiYXNlX2F0cl9vbiAm IH5UWFRfQVRUUl9DT0xPVVJfT05fTUFTSyk7Ci0JfSBlbHNlIHsKLQkgICAgLyoga2VlcCBjb2xv dXJzIGZyb20gc3RhbmRhcmQgYXR0cmlidXRlcyAqLwotCSAgICBhbGxfYXRyX29uID0gc3BlY2lh bF9hdHJfb24gfCBiYXNlX2F0cl9vbjsKLQl9CisKKwlhbGxfYXRyX29uID0gYmFzZV9hdHJfb247 CisJaWYgKHNwZWNpYWxfYXRyX29uICYgKFRYVEZHQ09MT1VSfFRYVE5PRkdDT0xPVVIpKQorCSAg ICBhbGxfYXRyX29uICY9IH4oVFhUX0FUVFJfRkdfT05fTUFTS3xUWFROT0ZHQ09MT1VSKTsKKwlp ZiAoc3BlY2lhbF9hdHJfb24gJiAoVFhUQkdDT0xPVVJ8VFhUTk9CR0NPTE9VUikpCisJICAgIGFs bF9hdHJfb24gJj0gfihUWFRfQVRUUl9CR19PTl9NQVNLfFRYVE5PQkdDT0xPVVIpOworCWFsbF9h dHJfb24gfD0gc3BlY2lhbF9hdHJfb247CiAJYWxsX2F0cl9vZmYgPSBUWFRfQVRUUl9PRkZfRlJP TV9PTihhbGxfYXRyX29uKTsKIAogCWlmICh0ID09IHNjcykJCQkvKiBpZiBjdXJzb3IgaXMgaGVy ZSwgcmVtZW1iZXIgaXQgKi8K --000000000000e544d205bed0e071--