'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.

The new function will be used in the next commit.

You cannot download just the "script". You need the entire directory/repo.

Pr fix issue #77

highlight ^old^new pattern

Add 'line' highlighter for the whole buffer

zle: don't override yank/yank-pop

`yank-pop` relies on the fact that the last zle command is `yank` or
`yank-pop` to work correctly. Rewriting them prevents this check to work
correctly breaking `yank-pop`.

This fix just disallow overriding of those two zle commands. As a
side-effect, syntax highlighting will not happen when using.

This fixes #99.

Update README.md

Edited links to Archlinux packages (the link to `zsh-syntax-highlighting-git` is out-of-date, and `zsh-syntax-highlighting` is now available in [community])

small change to find highlighting directory better

by extending the already in place mechanism of checking for the first
histchar to check for the second as well

Fix #121: sudo syntax highlighting incorrectly

Properly highlight array assignments

protect alias expansion from interpreting aliases as options

Do not leak a variable: cdpath_dir.

If one defines aliases like `++` the alias builtin tries to interprete these
as options so they have to be protected like this

    alias -- ++=true

The same goes for a call to `alias` in order to expand the alias again.

This code is more lenient than bash.  Examples:

    $ x[y[]=
    zsh: no matches found: x[y[]=
    $ x[][]=
    zsh: no matches found: x[][]=

The proper solution is to look inside the [...] and make sure that all
unescaped/unquoted square brackes are matched, but that is a heck of
a lot more complicated than this simple 8-character patch.

Zsh does not allow the variable name or the equals sign to be quoted or
escaped.  The previous code incorrectly highlighted the following
examples as assignments:

    $ 'x=y'
    zsh: command not found: x=y
    $ x\=y
    zsh: command not found: x=y
    $ "x"=y
    zsh: command not found: x=y
    $ \x=y
    zsh: command not found: x=y

Leaking a variable that holds a path in CDPATH could easily end up appearing on your prompt like `~cdpath_dir/subdir`.

Parse sudo command line in order to highlight the options correctly

Highlighted dollar variable ver. 2

Comments added