7e7e291b20 broke 'zle -C' completions, as reported in #278 just now.

Re-Fixes zsh-users/zsh-syntax-highlighting#278.

The last commit inadvertently broke interactive use, although the test suite passed.

See issue #278.

The 'eval' was never needed, and the lack of proper quoting of the interpolated
variables caused issues, such as #278.

Fixes zsh-users/zsh-syntax-highlighting#278.

- 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.

Fixes zsh-users/zsh-syntax-highlighting#162.

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.

Fixes zsh-users/zsh-syntax-highlighting#215.

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

Currently, this only works in installed trees and exported tarballs; the
parameter is left unset when running directly from a git worktree.

Fixes issue #213.

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.

Store it in a separate file so OS packages and 'make install' (issue #177) can
reuse it.

Follow-up to 908c4fe150.

Intended to fix fix zsh-users/zsh-syntax-highlighting#206.

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.

Followup to 908c4fe150.
Found by test-perfs.zsh.

Set WARN_CREATE_GLOBAL to prevent recurrence.

Fixes zsh-users/zsh-syntax-highlighting#192.

Have widgets return EXIT_SUCCESS.

Let $zle_highlight[paste] override $region_highlight.

Let $zle_highlight[region] override $region_highlight.

Partly reverts eb9870f4db which was PR #143 to
fix issue #99.

`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.

Signed-off-by: Takeshi Banse <takebi@laafc.net>

Signed-off-by: Takeshi Banse <takebi@laafc.net>