zsh/macOS bug: http://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=42891

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.