Re: How to get syntax highlighting working??

Re: How to get syntax highlighting working??

[Wayne Davison]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

While playing with this syntax highlighting code, I've come to the
conclusion that it would be much nicer to have a hook where the zle code
asks for a changed line to be highlighted.  This avoids having to create
functions for an ever-changing plethora of zle functions, and makes things
like push-line, yank, yank-pop, delete-char-or-list, and who-knows-what-else
Just Work (all of which have issues when using override widgets).

Here's a patch for zsh:

  http://opencoder.net/zle-set-highlight-hook.patch

Thoughts?  I really like this single hook point for highlighting.

With that change, the init code for the zsh-syntax-highlighting code becomes
this simple line:

  zle -N zle-set-highlight _zsh_highlight-zle-buffer

Then, just to make the shell code a little more optimal, I added the
following to the top of _zsh_highlight-zle-buffer function (to avoid
identical highlight processing):

  [[ ${ZSH_PRIOR_HIGHLIGHTED_BUFFER:-} == $BUFFER ]] && return
  ZSH_PRIOR_HIGHLIGHTED_BUFFER=$BUFFER

..wayne..

Re: How to get syntax highlighting working??

[Bart Schaefer]

On Dec 31, 10:28am, Wayne Davison wrote:
} 
} While playing with this syntax highlighting code, I've come to the
} conclusion that it would be much nicer to have a hook where the zle code
} asks for a changed line to be highlighted.

I've been thinking for a couple of days now about some related ideas.

I loaded the zsh-syntax-highlighting script from github but found it
to be *agonizingly* slow when running zed (or on any other significant
multi-line buffer), because it recomputes the colorization of the whole
buffer in shell code on every keystroke -- including movement up or
down in the buffer.

Several changes could improve this; (1) don't re-highlight if the buffer
hasn't changed [your edit to _zsh_highlight-zle-buffer]; (2) highlight
incrementally based on $CURSOR rather than starting over with a fresh
${(z)BUFFER} on every change; and (3) get some help from the C code,
which presently isn't available.

This is exactly the reason that completion has so many helper builtins
to figure out the context around the cursor position.  Perhaps the code
for completion could be repurposed for this; in fact perhaps a way to
approach it without hacking new C code directly, is to restructure the
colorize-zle-buffer function such that it becomes a completion widget
(one which always succeeds without adding any matches), and then invoke
that with "zle colorize-zle-buffer" instead of a direct call.

} This avoids having to create functions for an ever-changing plethora
} of zle functions, and makes things like push-line, yank, yank-pop,
} delete-char-or-list, and who-knows-what-else Just Work (all of which
} have issues when using override widgets).

Aside:  It appears the thread beginning users/15493 then workers/28369
never went anywhere (about making the zle hooks into arrays of function
or widget names).

} Here's a patch for zsh:
} 
}   http://opencoder.net/zle-set-highlight-hook.patch
} 
} Thoughts?  I really like this single hook point for highlighting.

Yes, this makes good sense.

-- 

Re: How to get syntax highlighting working??

[Mikael Magnusson]

On 31 December 2010 21:21, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Dec 31, 10:28am, Wayne Davison wrote:
> }
> } While playing with this syntax highlighting code, I've come to the
> } conclusion that it would be much nicer to have a hook where the zle code
> } asks for a changed line to be highlighted.
>
> I've been thinking for a couple of days now about some related ideas.
>
> I loaded the zsh-syntax-highlighting script from github but found it
> to be *agonizingly* slow when running zed (or on any other significant
> multi-line buffer), because it recomputes the colorization of the whole
> buffer in shell code on every keystroke -- including movement up or
> down in the buffer.
>
> Several changes could improve this; (1) don't re-highlight if the buffer
> hasn't changed [your edit to _zsh_highlight-zle-buffer]; (2) highlight
> incrementally based on $CURSOR rather than starting over with a fresh
> ${(z)BUFFER} on every change; and (3) get some help from the C code,
> which presently isn't available.
>
> This is exactly the reason that completion has so many helper builtins
> to figure out the context around the cursor position.  Perhaps the code
> for completion could be repurposed for this; in fact perhaps a way to
> approach it without hacking new C code directly, is to restructure the
> colorize-zle-buffer function such that it becomes a completion widget
> (one which always succeeds without adding any matches), and then invoke
> that with "zle colorize-zle-buffer" instead of a direct call.
>
> } This avoids having to create functions for an ever-changing plethora
> } of zle functions, and makes things like push-line, yank, yank-pop,
> } delete-char-or-list, and who-knows-what-else Just Work (all of which
> } have issues when using override widgets).
>
> Aside:  It appears the thread beginning users/15493 then workers/28369
> never went anywhere (about making the zle hooks into arrays of function
> or widget names).
>
> } Here's a patch for zsh:
> }
> }   http://opencoder.net/zle-set-highlight-hook.patch
> }
> } Thoughts?  I really like this single hook point for highlighting.
>
> Yes, this makes good sense.

I haven't compared the two approaches, or even tried the stuff
mentioned in this thread, but this is what I've done.
http://git.mika.l3ib.org/?p=zsh-cvs.git;a=commitdiff;h=74e0abb29894d87a7cfe045bc01167e9a56f73e3
patch to zsh adding a hook in zrefresh. As you may be able to tell,
all it does is highlight matching braces.

My general experience fiddling with adding new hooks is that some
stuff you do has unexpected consequences in completely unrelated
places, as the first comment mentions, due to almost nothing in zsh
being re-entrant.

#This uses =~ to avoid conflicting with isearch (some static vars get
overwritten)
function _line_redraw_brace_detect() {
  local char=$BUFFER[pos]
  if [[ $char =~ '\(' ]]; then
    dir=1
    that=')'
  elif [[ $char =~ '\)' ]]; then
    dir=-1
    that='('
  elif [[ $char =~ '\[' ]]; then
    dir=1
    that=']'
  elif [[ $char =~ '\]' ]]; then
    dir=-1
    that='['
  elif [[ $char =~ '\{' ]]; then
    dir=1
    that='}'
  elif [[ $char =~ '\}' ]]; then
    dir=-1
    that='{'
  fi
}

function _line_redraw() {
  unset region_highlight
  [[ $_IS_PASTING = 1 ]] && return

  [[ $__zle_line_accepted -gt 0 ]] && {
    (( __zle_line_accepted-- ))
    return
  }
  #this stuff is so slow
  [[ $#BUFFER -gt 250 ]] && { zle -D zle-line-pre-redraw; return }

  #hilight matching parens,braces,brackets
  local ct=1 pos=$((CURSOR+1)) cpos dir this that
  _line_redraw_brace_detect
  (( ! dir )) && {
    (( pos-- ))
    _line_redraw_brace_detect
  }
  (( ! dir )) && return
  this=$BUFFER[pos]
  cpos=$pos
  while (( ((dir > 0) ? (pos < $#BUFFER) : pos > 0) && ct )) {
    (( pos+=dir ))
    [[ $BUFFER[pos] == $that ]] && (( ct-- ))
    [[ $BUFFER[pos] == $this ]] && (( ct++ ))
  }
  (( ct )) ||
    region_highlight=("$((cpos-1)) $cpos bold,bg=cyan,fg=black"
                      "$((pos-1)) $pos bold,bg=cyan,fg=black")
}

Now that I look at it, I could probably replace the while loop with a
(I:something:b:something:) subscript...

-- 
Mikael Magnusson