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

* danielsh/i199-semicolon-v1:
  Fix regression: Highlight ';' as commandseparator.
  Follow-up to 547b8be30461: Fix $observed_result calculation.

Fixes zsh-syntax-highlghting/zsh-users#199.

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.

Have widgets return EXIT_SUCCESS.

In region_highlight, a spec of the form 'i j foo' with i >= j should have no effect.
Before this commit, however, the {$i..$j} range would happily expand to (5 4 3)
if i > j were the case (e.g., i=5 and j=3).

This breaks vanilla-newline.zsh; the next commit will fix that.

This way, each test can set custom styles to specific highlight contexts
(to differentiate those contexts) without affecting later tests.

Otherwise, *.rej patch files would be run by zsh, with unpredictable results.

Fixes zsh-users/zsh-syntax-highlighting#165.
Fixes zsh-users/zsh-syntax-highlighting#175.

* danielsh/i165-region-v1:
  Highlight yanks/pastes on top of syntax highlighting.
  Highlight the region on top of syntax highlighting.

The path string ends at offset 26, not 23.

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

The one revision made on master between this branch's creation and merge
already uses correct offsets.

* danielsh/i195-tests-offbyone-v1:
  New test for dollar-double-quoted-argument.
  test harness: Fix off-by-one discrepancy between observed and expected.

This exercises the previous patch.

Fixes issue #195.

This does not yet highlight backslash escapes within them.

Let $zle_highlight[paste] override $region_highlight.

Let $zle_highlight[region] override $region_highlight.

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#189.

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

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.

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

Partly reverts eb9870f4db which was PR #143 to
fix issue #99.

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

* upstream/pr/179:
  Don't parse first word of array assignment as command

* upstream/pr/161:
  Don't highlight prefix redirections as error

* upstream/pr/159:
  Support literal newlines, part 2
  Update comments. No functional change.
  Highlight the first part of multiline strings correctly
  Support literal newlines
  Support backslash continuations
  Support multiline strings
  Refactoring, no functional change

* origin/pr/158:
  README: give the rationale for the at-end-of-.zshrc requirement

Based on a patch by George Angelopoulos <george@usermod.net>.

Closes #149.

Fixes zsh-users/zsh-syntax-highlighting#178

Fixes zsh-users/zsh-syntax-highlighting#146

Given the following input:
    PREBUFFER=$'echo "foo\n'
    BUFFER='bar"'
This patch causes the '"foo' part to be highlighted as a string.  There
is no test because the tests only check highlighting of BUFFER, and 'bar"'
is already highlighted correctly.