Fixes #449.

The bug is not specific to 5.3.1.

Fixes #426.

Review-by: Matthew Martin, me

Fixes #409.

ZSH versions less than 5.3.2 (or 5.4) have a bug that prevents
`history-incremental-pattern-search-backward` for working
correctly (the history stops searching after the first found item).

Closes #407

Fixes #400.

Fixes #392.

Fixes #390.

The heretofore code warned once per keypress.

This caused warnings with `setopt warn_create_global`.

This manifested in completion of the form «./foo<TAB>» where there happened to
be a program called 'foo' in $PATH.

Fixes #354.
Closes #355.

This updates the docs and the driver, in a manner backwards compatible with
existing highlighters.  (None of the highlighters are touched by this change,
yet tests continue to pass.)

Part of issue #329.

Re-fixes #305.

Part of issue #305.

This fixes an infinite recursion in zsh without zle-line-pre-redraw [≤5.2] in
the following situation:

% source zsh-syntax-highlighting.zsh
% eval "my-self-insert() { zle -M 'foobar'; ${(q)widgets[self-insert]#*:} \"\$@\" }"
% zle -N self-insert my-self-insert
% source zsh-syntax-highlighting.zsh

Fixes #305.

This patch causes a behaviour difference in the [i257] scenario:

- Before this change, the zle_highlight[isearch] is applied and z-sy-h's
  highlighting isn't.

- With this change, both zle_highlight[isearch] and z-sy-h's
  highlighting are applied, so «echo foo» renders the first word in green
  underline (fg=green from ZSH_HIGHLIGHT_STYLES[builtin], underline from
  zle_highlight[isearch]).

This patch causes the presuppositional FAQ entry added in
a8fe22d422 to be correct.

This is part of #261, of which #288 was a spin-off.

[i257] https://github.com/zsh-users/zsh-syntax-highlighting/pull/257#issuecomment-168394665

zsh version 5.2 and lower don't support ISEARCHMATCH_ACTIVE and
we are unable to re-apply zle_highlight on top. Therefore it is
impossible to see the underlined matched area.

Since that information is more important, completely disable
highlighting in isearch in that case.

To do that, we need to make sure we are actually called when
something changes in isearch.

Trumps #257.

The FAQ entry presupposes #245 will be fixed (in time for the release) too.

Special handling for cursor imprint or partial path highlighting
is needed in more cases than accept-*. For example when accepting
a line from isearch, no accept-* widget is invoked.

The proper way is to use zle-line-finish.

Trumps #259.
Fixes #284.

Just in case one of the interpolated variables contains a backslash.

Part of issue #329.

Avoids a fork.

Instead, use the %N prompt expando, as suggested by Bart in users/21637.

Avoid the `print -P %N` syntax to save a fork on Cygwin, at the expense
of not supporting zsh's from 2001 through c. 2004 vintages.

Fixes #338.

Two instances.

Fixes #267.

ISEARCH_ACTIVE was renamed ISEARCHMATCH_ACTIVE in workers/38921
(commit f06be0ffcf2c to zsh itself).

Fixes #299.

Closes #287. Testing the keys directly removes the need for
unused_highlight which will be removed next.

_zsh_highlight_add_highlight appends to region_highlight $1 $2 and the
next non-null parameter. If there is no non-null parameter, do nothing,
This is so that highlighters can add a style with fallbacks if the most
specific style is not defined. If none of the applicable styles are
defined, do the right thing and don't add an invalid entry to
region_highlight.

The pattern highlighter doesn't use this function as it'd need too large
of an API change.

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.