- Extract duplicated code into a new function.
This makes it easier to add support for other entries in the
future, that cannot be accessed in the current version of zsh
(isearch, suffix).
- Make decision logic more comprehensible.
- Respect deliberately empty entries in zle_highlight.
Don't force the default value when the user deliberately sets
an entry in zle_highlight to the empty string.
For example
zle_highligh(paste:)
to disable paste highlighting completely.
Skipping when $cur_widgets == user:$cur_widget was introduced
with 776453cb5b. However there
are cases where this is not just an 'already rebound' event, but
simply a normal widget whose function name happens to be identical
to its widget name.
Example:
expand-absolute-path is a widget whose function name is also
expand-absolute-path. No reason why this should be ignored.
Another example:
edit-command-line
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.
