region_highlight cancels styles set in zle_highlight

region_highlight cancels styles set in zle_highlight

[Mikael Magnusson]

foo() { region_highlight=("5 10 bold") }
zle_highlight=(default:bg=blue)
zle -N foo
bindkey '^T' foo
type a few words, then press ^T and ^L, note how after character 10,
the line is no longer blue.

What I'm actually trying to do is highlight the pre/post display stuff
in narrow-to-region.

-- 
Mikael Magnusson

Re: region_highlight cancels styles set in zle_highlight

[Mikael Magnusson]

On 1 June 2011 17:57, Mikael Magnusson <mikachu@gmail.com> wrote:
> foo() { region_highlight=("5 10 bold") }
> zle_highlight=(default:bg=blue)
> zle -N foo
> bindkey '^T' foo
> type a few words, then press ^T and ^L, note how after character 10,
> the line is no longer blue.
>
> What I'm actually trying to do is highlight the pre/post display stuff
> in narrow-to-region.

Hm, if I use bg=red instead of/in addition to bold, it works.

-- 
Mikael Magnusson

region_highlight cancels styles set in zle_highlight

[Daniel Shahaf]

How do $zle_highlight and $region_highlight interact?  Which one takes
precedence if a certain byte range is covered by both?

(This came up in [1], which contains observations but no discussion.)

Empirically:

- if both $zle_highlight[region] and $region_highlight apply to a certain
  byte range, then that byte range is highlighted according to the
  former, only:

    bindkey -v
    zle_highlight=( region:underline )
    f() { region_highlight=("0 10 fg=red") }; zle -N f; bindkey -a ^T f
    echo foo bar<Esc><^T>v0
    [the 'echo foo bar' is red but not underlined]

- if both $zle_highlight[special] and $region_highlight apply to a certain
  byte, then both highlightings are applied "on top of" each other:

    zle_highlight=( special:underline )     
    f() { region_highlight=("0 10 fg=red") }; zle -N f; bindkey ^T f
    echo ^T bar «invoke f»
    [the ^T is red and underlined]
  
How does this work, in general?  When does zle merge the settings from
the two arrays, and when does one array override the other?

Thanks,

Daniel
(Background: zsh-syntax-highlighting wants the zle_highlight[region]
highlighting to be applied "on top of" the syntax highlighting [2]; the
workaround [3] works with current zle behaviour of "region_highlight
overrides zle_highlight[region]".)

[1] http://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=29425
    Subject: region_highlight cancels styles set in zle_highlight
[2] https://github.com/zsh-users/zsh-syntax-highlighting/issues/165
[3] https://github.com/jimmijj/zsh-syntax-highlighting/commit/ece762e81798bc4448bf17f68a4792d1117dc032

Re: region_highlight cancels styles set in zle_highlight

[Peter Stephenson]

On Sat, 5 Sep 2015 10:44:49 +0000
Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> How do $zle_highlight and $region_highlight interact?  Which one takes
> precedence if a certain byte range is covered by both?

The special forms of highlight (the ones that apply to regions, so not,
for example, unprintable characters) are treated as the initial set of
entries in the array of highlights to apply, with any user-specified
ones in region_highlight following in order, with later values
overriding earlier ones.

pws

Re: region_highlight cancels styles set in zle_highlight

[Daniel Shahaf]

Peter Stephenson wrote on Sun, Sep 06, 2015 at 18:22:30 +0100:
> On Sat, 5 Sep 2015 10:44:49 +0000
> Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > How do $zle_highlight and $region_highlight interact?  Which one takes
> > precedence if a certain byte range is covered by both?
> 
> The special forms of highlight (the ones that apply to regions, so not,
> for example, unprintable characters) are treated as the initial set of
> entries in the array of highlights to apply, with any user-specified
> ones in region_highlight following in order, with later values
> overriding earlier ones.

Thanks.  Patch to doc this:

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 4e93695..22e8111 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -955,6 +955,11 @@ any predisplay string should be highlighted in bold.
 
 Note that the effect of tt(region_highlight) is not saved and disappears
 as soon as the line is accepted.
+
+The final highlighting on the command line depends on both tt(region_highlight)
+and tt(zle_highlight); see
+ifzman(the section CHARACTER HIGHLIGHTING below)\
+ifnzman(noderef(Character Highlighting)) for details.
 )
 vindex(UNDO_CHANGE_NO)
 item(tt(UNDO_CHANGE_NO) (integer))(
@@ -2521,6 +2526,12 @@ Following a command to paste text, the characters that were inserted.
 )
 enditem()
 
+When tt(region_highlight) is set, the contexts that describe a region DASH()-
+tt(isearch), tt(region), and tt(paste) DASH()-
+are applied first, then tt(region_highlight) is applied, then the remaining
+tt(zle_highlight) contexts are applied.  If a particular character is
+affected by multiple specifications, the last specification wins.
+
 tt(zle_highlight) may contain additional fields for controlling how
 terminal sequences to change colours are output.  Each of the following is
 followed by a colon and a string in the same form as for key bindings.

Re: region_highlight cancels styles set in zle_highlight

[Peter Stephenson]

On Mon, 7 Sep 2015 02:08:14 +0000
Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Peter Stephenson wrote on Sun, Sep 06, 2015 at 18:22:30 +0100:
> > On Sat, 5 Sep 2015 10:44:49 +0000
> > Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > > How do $zle_highlight and $region_highlight interact?  Which one takes
> > > precedence if a certain byte range is covered by both?
> > 
> > The special forms of highlight (the ones that apply to regions, so not,
> > for example, unprintable characters) are treated as the initial set of
> > entries in the array of highlights to apply, with any user-specified
> > ones in region_highlight following in order, with later values
> > overriding earlier ones.
> 
> Thanks.  Patch to doc this:

Thanks, that's useful.

By the way, the code for this is fairly localised in
Src/Zle/zle_refresh.c, with the decisions made in the chunk of code at
the top of character loop in singlerefresh() after the comment
"Calculate attributes based on region": the special and user-defined
attributes have been coalesced into the array region_highlights at this
point.  So if there's a good argument for alternative or variant
behaviour it shouldn't be too difficult, by ZLE standards.

pws

-- 
Peter Stephenson | Principal Engineer Samsung Cambridge Solution Centre
Email: p.stephenson@samsung.com | Phone: +44 1223 434724 |
www.samsung.com

Re: region_highlight cancels styles set in zle_highlight

[Daniel Shahaf]

Peter Stephenson wrote on Mon, Sep 07, 2015 at 09:48:56 +0100:
> On Mon, 7 Sep 2015 02:08:14 +0000
> Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > Peter Stephenson wrote on Sun, Sep 06, 2015 at 18:22:30 +0100:
> > > On Sat, 5 Sep 2015 10:44:49 +0000
> > > Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > > > How do $zle_highlight and $region_highlight interact?  Which one takes
> > > > precedence if a certain byte range is covered by both?
> > > 
> > > The special forms of highlight (the ones that apply to regions, so not,
> > > for example, unprintable characters) are treated as the initial set of
> > > entries in the array of highlights to apply, with any user-specified
> > > ones in region_highlight following in order, with later values
> > > overriding earlier ones.
> > 
> > Thanks.  Patch to doc this:
> 
> Thanks, that's useful.

Committed with a small tweak to also list 'suffix' in the list of
zle_highlight contexts that apply prior to region_highlight.

> By the way, the code for this is fairly localised in
> Src/Zle/zle_refresh.c, with the decisions made in the chunk of code at
> the top of character loop in singlerefresh() after the comment
> "Calculate attributes based on region": the special and user-defined
> attributes have been coalesced into the array region_highlights at this
> point.  So if there's a good argument for alternative or variant
> behaviour it shouldn't be too difficult, by ZLE standards.

Thanks for the pointer, it was useful.

Cheers,

Daniel