No test because _zsh_highlight_main__type() falls back to 'type -w' which runs
'rehash' implicitly, so on systems where 'sudo' is installed it's not possible
to simulate its being absent.
Test by forcing _zsh_highlight_main__type() to return 'none' when the
argument is [[ $1 == 'sudo' ]], and: (1) Run 'make test' and confirm
that all tests either pass, or fail and the first test point that fails
is one that expects "sudo" at command position to be highlighted as
'command'; (2) In an interactive zsh, 'sudo' at command position is
highlighted as an error.
Merge remote-tracking branch 'upstream/pr/385'
* upstream/pr/385:
'main': Add regression test for previous commit.
'main': Fix bug: no start_pos=$end_pos in comment short path
Fixes#385.
Such a command word would, if not valid, fall through to the `type -w` case,
where the output would be misparsed, consequently the forward-compatible [arg0]
style would be used.
The fallback style name uses '_' in anticipation of a future auto-fallback
feature keyed on style names.
'arg0' was previously known as 'commandtypefromthefuture'.
Main highlighter run on itself, on the optimized version:
- optimized (8 runs, 3 last noted):
1.1201650000
1.1074430000
1.1263810000
- unoptimized (8 runs, 3 last noted):
1.5746400000
1.5115250000
1.5155440000
Average difference: 0.415907
Running main highlighter on itself (both runs are on the optimized
version):
- clean (8 runs, last 3 noted):
1.7007670000
1.7330720000
1.7038810000
- optimized (8 runs, last 3 noted):
1.5007230000
1.5142960000
1.4973320000
Average difference: 0.208456
When parsing main-highlighter with itself, the *_check_path function is
called 426 times. Note that there are 686 region_highlight resulting
entries.
This is a prerequisite for the next commit.
The incumbent code was wrong: the test of $in_redirection in the first hunk
would never have seen «(( in_redirection == 2 ))». That had no visible
effect since options to sudo don't look like redirection operators.
Special handling for cursor imprint or partial path highlighting
is needed in more cases than accept-*. For example when accepting
a line from isearch, no accept-* widget is invoked.
The proper way is to use zle-line-finish.
Trumps #259.
Fixes#284.
Merge remote-tracking branch 'upstream/pr/342'
* upstream/pr/342:
'main': Highlight a broken symlink as a file.
tests: Add an XFail test for issue #342.
If the separator feature is disabled, this makes it possible to
change the main 'path' styles in a running session without the
need to touch the '_pathseparator' styles, too.
Merge remote-tracking branch 'upstream/pr/331'
* upstream/pr/331:
'main': Try the "non-command word" codepath when a word may be either a command word or a non-command word.
* upstream/pr/319:
tests: Extend issue #290 test with another variant.
'main': Fix issue #290, «Mishighlights "longloops" 'repeat'».
tests: New test for issue #290, «Mishighlights "longloops" 'repeat'».
Assignments to positional parameters using scalar assignment syntax is
a feature: it is covered by upstream's test suite ("append to positional
parameter" in Test/A06assign.ztst).
This commit is based on the work done by
Jorge Israel Peña (blaenk) in #136.
Changes:
* Adjusted to changes on the latest master branch.
* Use regular path highlighter colors by default.
* Break out early if the separator color is the same to
improve performance.
* Tests.
If possible, try to use the zsh/parameter module to get
information about a shell words.
This avoids subshells and is a huge speed improvement
on systems such as cygwin.
Note 1:
$commands does not know about PATH_DIRS. So in case
PATH_DIRS is set, 'type -w' is still used if nothing
else matches.
Note 2:
zsh/parameter can't distinguish between 'command' and
'hashed'. Adjusted the test for that case to XFAIL.
The ideal solution would be if whence had an option to
put the result in REPLY instead of printing it to stdout.
* upstream/pr/308:
'main': Fix issue #302, "Process substitution misparsed as redirection".
'main': Factor out common code. No functional change.
'main': Add a regression test for issue #302, "Process substitution misparsed as redirection".
Consider indexing long buffers (say 300 chars). E.g. following line:
integer offset=${${buf[start_pos+1,len]}[(i)$needle]}
will gradually go into large indices for first index [a,] and be kept
at large index for second index [,b]. Instead, we can remove already
processed characters from buf:
proc_buf="${proc_buf[offset + $#arg + 1,-1]}"
$offset and $#arg are small, first index will not be large. $proc_buf
will be smaller and smaller and the second index [,-1] will run shorter
and shorter.
_zsh_highlight_add_highlight appends to region_highlight $1 $2 and the
next non-null parameter. If there is no non-null parameter, do nothing,
This is so that highlighters can add a style with fallbacks if the most
specific style is not defined. If none of the applicable styles are
defined, do the right thing and don't add an invalid entry to
region_highlight.
The pattern highlighter doesn't use this function as it'd need too large
of an API change.
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
