The '--' guard was correct; it was there to guard against arguments belonging
to the syntax «zle widget [ -n num ] [ -Nw ] [ -K keymap ] args».
For example, this affected using <backward-kill-word> over
BUFFER="-w "
CURSOR=3
after
autoload -Uz select-word-style
select-word-style default
zstyle ':zle:backward-kill-word' word-style shell
.
This reverts commit c808d2187a.
Just because a widget starts with _ does not mean it should be
skipped when rebinding. The only reason widgets need to be skipped
is when their function name start with _zsh_highlight_widget*,
which is checked later.
Example:
_expand_alias (^Xa) needs to be wrapped.
The exclusion of _* was introduced in 186d80054a
to fix#65, but it is not needed. The relevant exclusion of
_zsh_highlight_widget* is already enough due to the case statement.
It's the widget's caller's responsibility, not ours, to add '--' where due. If
we do it, two instances of '--' might result. (I haven't been able to provoke
this problem.)
If this commit causes problems, the cause would be widget-callers that don't
pass '--' although they should.
All these files should be sourced, not executed; and Debian's lintian complains:
W: zsh-syntax-highlighting: script-not-executable usr/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh
This reverts commit 8e7c26f489.
Currently, after a 'yank', paste highlighting (via $YANK_ACTIVE in zsh 5.1.1)
is applied but other highlighting (e.g., string highlighting when the yanked
text is «"foo» as a new word) is not.
See issue #183 for context.
Conflicts:
zsh-syntax-highlighting.zsh
As explained in #143 (which was a PR for #99), 'yank-pop' only works when the
previous widget has the ZLE_YANK flag, which means wrapping the 'yank' widget
breaks the 'yank-pop' widget (makes it a no-op). However, that is a reason
against wrapping the 'yank' widget, but not against wrapping the 'yank-pop'
widget. Indeed, if 'yank-pop' is wrapped but 'yank' isn't, then yank-pop
functions correctly and updates highlighting properly.
To unbreak yank-pop, either 'yank' should be excluded from wrapping, or one of
the fixes mentioned on issue #183 should be applied.
Sourcing zsh-syntax-highlighting.zsh without FUNCTION_ARGZERO doesn't work (for
reasons unrelated to this branch), but now errors out gracefully. The failure mode
before this branch was:
zsh-syntax-highlighting: highlighters directory '/usr/local/bin/highlighters' not found.
where /usr/local/bin is dirname() of the zsh binary.
See issue #137. A reproduction recipe for testing this change:
$ zsh -f
% bindkey -e
% source <the script from http://www.zsh.org/mla/users/2014/msg00321.html users/18584>
% source zsh-syntax-highlighting.zsh
% echo foo
% echo bar
% <^R>echo<^R>
This finds the 'echo foo' with this change but not without it.
`yank-pop` relies on the fact that the last zle command is `yank` or
`yank-pop` to work correctly. Rewriting them prevents this check to work
correctly breaking `yank-pop`.
This fix just disallow overriding of those two zle commands. As a
side-effect, syntax highlighting will not happen when using.
This fixes#99.
* Allow to override highlighters directory through `ZSH_HIGHLIGHT_HIGHLIGHTERS_DIR`
* Handle spaces in the directory path
* Use Zsh builtin "h" modifier instead of `dirname`
* Don't override user defined styles
* Better modularisation of highlighters
* Allow to define which highlighters are activated
* Allow to define the order in which they are defined
* Minor performance optimizations
* Fixed some variables leak
* Improve documentation
* Brackets highlighter: use ZSH_HIGHLIGHT_STYLES instead of a specific array
Originally, zsh-syntax-highlighting called highlight functions at every inputs.
It's OK for user's keyboard inputs. But when long inputs come from clipboard,
it cause noticeable slowdown.
The script still works on its own, highlighters in highlighters/ are
loaded as addons if present.
Signed-off-by: Julien Nicoulaud <julien.nicoulaud@gmail.com>
For easily extending the highlighting behavior, split the
actual highlighting function into some pieces.
For example "_zsh_main-highlight" transformed into,
1) An actual highlighting function which updates the
`region_highlight` on its own. (_zsh_main-highlight)
2) A predicate which determines whether its highlighting function
(in this case `_zsh_main-highlight`) should be called or not.
(_zsh_buffer-modified-p)
Likewise, `_zsh_highlight-bracket-match` and
`_zsh_highlight-bracket-match-p` are born.
Eventually, `_zsh_highlight-zle-buffer` coordinates above these
functions and maintain some internal state variables.
Finally, added `_zsh_add-highlighter` a little syntactic-sugar-ish
function to register the highlighting functions in an appropriate manner.
Signed-off-by: Takeshi Banse <takebi@laafc.net>
Make `_zsh_highlight-zle-buffer` just a hands-off.
Now, `_zsh_highlight-zle-buffer` calls each ZSH_HIGHLIGHT_FUNCTIONS
in turn. The former `_zsh_highlight-zle-buffer` is renamed to
`_zsh_main-highlight.`
Signed-off-by: Takeshi Banse <takebi@laafc.net>
% bindkey "^I" complete-word
% bi<TAB>
If we had not source the zsh-syntax-highlighting.zsh, it could
complete something. This is due to that `complete-word` will be
rebinded with 'zle -N $clean_event'.
Signed-off-by: Takeshi Banse <takebi@laafc.net>
Currently, each completion widgets will be re-installed, but its
function will be statically associated with `_main_complete`.
We can get this function name via $widget[$event] which is the
zsh's zsh/zleparameter module's feature. We can use this information
for `zle -C`ing.
Signed-off-by: Takeshi Banse <takebi@laafc.net>
