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>

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