zsh older than workers/28418 (zsh revision 23bdfc7fd2a012d5205ed22d18eb39e41c8fbc95)
doesn't support the «${name:offset:length}» syntax. Therefore, use the older
«$name[start,end]» syntax instead.
Followup to 3cb58fd7d7, "Optimization: -1 is
extra computation of string length internally".
Fixeszsh-users/zsh-syntax-highlighting#279.
./parse.zsh "zplugin.zsh" > out_norm.txt 106,17s user 7,84s system 98% cpu 1:55,85 total
./parse.zsh "zplugin.zsh" > out_opt.txt 51,91s user 7,44s system 99% cpu 59,912 total
% wc -l zplugin.zsh
3188 zplugin.zsh
The important part of this change is removing the second conjunct from the
condition; the remainder of the change gives one example of when that matters.
The following warnings are issued by zsh as of zsh-workers/37018 (commit
de9effbce601 to zsh itself):
_zsh_highlight_main_highlighter_highlight_dollar_string:17: array parameter match created globally in function _zsh_highlight_main_highlighter_highlight_dollar_string
_zsh_highlight_main_highlighter_highlight_dollar_string:17: array parameter mbegin created globally in function _zsh_highlight_main_highlighter_highlight_dollar_string
_zsh_highlight_main_highlighter_highlight_dollar_string:17: array parameter mend created globally in function _zsh_highlight_main_highlighter_highlight_dollar_string
_zsh_highlight_main_highlighter_highlight_dollar_string:17: numeric parameter parameter MBEGIN created globally in function _zsh_highlight_main_highlighter_highlight_dollar_string
_zsh_highlight_main_highlighter_highlight_dollar_string:17: numeric parameter parameter MEND created globally in function _zsh_highlight_main_highlighter_highlight_dollar_string
_zsh_highlight_main_highlighter_highlight_dollar_string:17: scalar parameter MATCH created globally in function _zsh_highlight_main_highlighter_highlight_dollar_string
_zsh_highlight_main_highlighter_highlight_string:11: array parameter match created globally in function _zsh_highlight_main_highlighter_highlight_string
_zsh_highlight_main_highlighter_highlight_string:11: array parameter mbegin created globally in function _zsh_highlight_main_highlighter_highlight_string
_zsh_highlight_main_highlighter_highlight_string:11: array parameter mend created globally in function _zsh_highlight_main_highlighter_highlight_string
_zsh_highlight_main_highlighter_highlight_string:11: numeric parameter parameter MBEGIN created globally in function _zsh_highlight_main_highlighter_highlight_string
_zsh_highlight_main_highlighter_highlight_string:11: numeric parameter parameter MEND created globally in function _zsh_highlight_main_highlighter_highlight_string
_zsh_highlight_main_highlighter_highlight_string:11: scalar parameter MATCH created globally in function _zsh_highlight_main_highlighter_highlight_string
zsh prior to workers/32609 (commit 9d47e8398d299e53ffe4e7ddf3731d2fedae9948)
does not support the (-n)-less «[[ $var ]]» syntax.
Fixeszsh-users/zsh-syntax-highlighting#225.
The change of behaviour is triggered by test-data/sudo-redirection.zsh: the iteration
on "otheruser" sets $next_word to ":regular::sudo_opt::start::sudo_opt::start:" before
this patch, but to ":regular::sudo_opt::start:" after it (note the deduplication).
The fix for issue #9 was accidentally broken by the penultimate commit.
Note that we don't care about aliases to ZSH_HIGHLIGHT_TOKENS_COMMANDSEPARATOR
entries, since the code deals with aliases at command position.
Use this to remove [path_prefix] highlighting during accept-* widgets.
This causes ": file.tx<CR>" to remove the underline from "file.tx", like
": file.tx<SPACE>" already does. (Assume 'file.txt' exists.)
Fixeszsh-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.
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).
Fixeszsh-users/zsh-syntax-highlighting#204.
Correct highlighting of backslash escapes within "" strings: highlight only
the four specific escape sequences defined there.
Fixeszsh-users/zsh-syntax-highlighting#196.
'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")
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.
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
* Don't override user defined styles
* Better modularisation of highlighters
* Allow to define which highlighters are activated
* Allow to define the order in which they are defined
* Minor performance optimizations
* Fixed some variables leak
* Improve documentation
* Brackets highlighter: use ZSH_HIGHLIGHT_STYLES instead of a specific array
