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

Part of issue #201.

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.

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.

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

Now, «"$42foo"» doesn't highlight the «foo», and «"$bar» highlights the «r».

Set WARN_CREATE_GLOBAL to prevent recurrence.

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

This is part of issue zsh-users/zsh-syntax-highlighting#198.

* highlighters/main/test-data/hashed-command.zsh:
    Set the right region key.  This makes the test more specific.
    (Issue #184 would have caught this bug.)

This is part of issue zsh-users/zsh-syntax-highlighting#198.

This was broken by c2b9327b07
and tracked as zsh-users/zsh-syntax-highlighting#199.

This fixes the vanilla-newline.zsh test, which was was (consciously) broken
by the previous commit.

This is part of issue zsh-users/zsh-syntax-highlighting#198.

This is part of issue zsh-users/zsh-syntax-highlighting#198.

This is part of issue zsh-users/zsh-syntax-highlighting#198.

This is part of issue zsh-users/zsh-syntax-highlighting#198.

This is part of issue zsh-users/zsh-syntax-highlighting#198.

Notably, the 'single-hyphen-option' and 'assign' contexts both default to the
'none' style, so before this patch, the tests would not have detected a failure
to apply those two contexts.

For other contexts, using $unused_highlight only helps detect the case where
the right highlight style (e.g., 'fg=yellow') is used as a result of applying
the wrong context — which should be a theoretical failure mode.

This is part of zsh-users/zsh-syntax-highlighting#198.

The path string ends at offset 26, not 23.

This exercises the previous patch.

Fixes issue #195.

This does not yet highlight backslash escapes within them.

Add an underline, since they are at command word position but will be executed
by something else.

Suggested-by: Daniel Hahler

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

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

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

'local' is a reserved word in zsh 5.1 but not in earlier versions [1].
Therefore, under zsh older than 5.1, quoting is required.

This manifested as random «builtin=''» in emitted to the terminal, and
commands (such as 'echo') highlighted as errors (in red).

[1] https://github.com/zsh-users/zsh/blob/master/README#L46
    (the section "Incompatibilites between 5.0.8 and 5.1")

Similar to zsh-users/zsh-syntax-highlighting#97.