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

Tested with 'bmake -B'.

Found-by: Carsten Hey

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.

* danielsh/versionstamp:
  versionstamp: Set up '.revision-hash' file.
  versionstamp: Handle NO_FUNCTION_ARGZERO.
  Set the version number.

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.

Don't modify $(PREFIX) from 'make', only from 'make install'.

Fixes issue #177 (using a different branch than the originally-proposed one).

* phy1729/makefile:
  Makefile: Add default for INSTALL
  Makefile: exit non-zero for a failed test
  Makefile: Add test target
  Add Makefile

Suggested-by: Ory Band
(on issue #169)

This causes '~/bin/foo' to highlight as a command, rather than as a file.

Part of issue #201.

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

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

Fixes zsh-users/zsh-syntax-highlighting#188 in the case that both the
opening '((' and closing '))' have been typed,  The case that only the
opening '((' have been typed is also fixed, but requires a zsh development
build (zsh-5.1.1-52-g4bed2cf or newer); see comments within.

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

Followup to 219184f046d40cc723606797666dab18f8a6aea7, which fixed issue #196.

Related to issue #205.

Without this, redirections, history expansions, and command separators would
be matched by path_approx.

A test case is simply LBUFFER="<" RBUFFER="" (highlighted as redirection with this
fix and as path_approx without it).

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

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

* danielsh/i23-highlight-redirections:
  Highlight redirections.

Remove highlighting of hex and octal escapes in "" strings (which don't parse
those escapes), add it to $'' strings (which do), and correct the regexps.
Also add support for unicode \u/\U escapes.

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

* danielsh/i196-back-dollar-quoted-v1:
  back-dollar-quoted-argument: Correct an off-by-one.
  back-dollar-quoted-argument: Correct octal escape syntax.
  back-dollar-quoted-argument: Highlight \uHHHH and \UHHHHHHHH escapes.
  back-dollar-quoted-argument: Don't consider \0xHH a hex escape sequence.
  back-dollar-quoted-argument: Don't consider comma a hex character.
  Highlight backslash escapes within $'' strings.

Highlight the last character of a «\xHH» escape when it is the last thing in
LBUFFER.  This is similar to what b0cc02ed86 did
for issue #186.

A leading zero, as in '\0NNN', is permitted by 'echo' but not by 'print',
and «$''» follows 'print'.

A leading zero is not permitted in the '\xHH' syntax.

Character class syntax does not ignore commas between ranges.

Correct highlighting of backslash escapes within "" strings: highlight only
the four specific escape sequences defined there.

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

Found by code inspection; WARN_CREATE_GLOBAL missed this.

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.