As described in the last commit's log message, ${parameter_name_pattern]
explicitly matches positional parameters but ${parameters[$MATCH]}
expands to nothing in that case (when, e.g., [[ $MATCH == '1' ]]; note
this is equality of strings, not integers).
As a side effect, this removes the dependency on the zsh/parameter
module for expanding parameters.
On the test case, the behaviour was as follows:
+highlighters/main/main-highlighter.zsh:733> _zsh_highlight_main_highlighter__try_expand_parameter '$1'
+highlighters/main/main-highlighter.zsh:432> local arg='$1'
+highlighters/main/main-highlighter.zsh:433> unset reply
+highlighters/main/main-highlighter.zsh:439> local -a match mbegin mend
+highlighters/main/main-highlighter.zsh:440> local MATCH
+highlighters/main/main-highlighter.zsh:440> integer MBEGIN MEND
+highlighters/main/main-highlighter.zsh:441> local parameter_name
+highlighters/main/main-highlighter.zsh:442> local -a words
+highlighters/main/main-highlighter.zsh:443> [[ '$' != \$ ]]
+highlighters/main/main-highlighter.zsh:446> [[ 1 == { ]]
+highlighters/main/main-highlighter.zsh:449> parameter_name=1
+highlighters/main/main-highlighter.zsh:451> [[ none == none ]]
+highlighters/main/main-highlighter.zsh:451> zmodload -e zsh/parameter
+highlighters/main/main-highlighter.zsh:452> [[ ${parameter_name} -regex-match ^${~parameter_name_pattern}$ ]]
+highlighters/main/main-highlighter.zsh:453> [[ '' != *special* ]]
+highlighters/main/main-highlighter.zsh:456> case array-special (*array*|*assoc*)
+highlighters/main/main-highlighter.zsh:458> words=( '$1' )
+highlighters/main/main-highlighter.zsh:469> reply=( '$1' )
There are two problems here:
- In terms of _zsh_highlight_main_highlighter__try_expand_parameter's
pre- and postconditions, the expansion of the word «$1» (line 733)
included that same word (line 469).
That happened because word-to-be-expanded is passed to
_zsh_highlight_main_highlighter__try_expand_parameter as its first
positional parameter, and in this case the word happened to be «$1».
- Furthermore, the exclusion of special parameters (line 453) false
negatived. That happened because $parameter_name_pattern explicitly
allows positional parameters, but ${parameters[(e)1]} expands to
nothing. This will be fixed in the next commit.
Not a regression from 0.7.1.
Before this commit, if the value didn't begin with a dollar sign,
_zsh_highlight_main_highlighter__try_expand_parameter() would return 1
by accident.¹ Tweak the input validation to make this behaviour
explicit. No functional change.
¹ Specifically, it would return 1 because ${parameter_name}'s value
would be the empty string and ${parameter_name_pattern} wouldn't match
that.
(q-) passes through newlines and NUL bytes verbatim. Using (qqqq) ensures the
escaped string will be on a single line (as required by the TAP format) and be
readable even if it contains control characters.
Fixes an issue whereby the '# TODO "issue #687"' directive in the output of
opt-shwordsplit1.zsh was truncated, because the test itself had set the
SH_WORD_SPLIT option and that affected the evaluation of
«${(z)expected_region_highlight[i]}» in the test harness.
Furthermore, this patch also independently fixes the error under
zsh-5.0.8 and earlier that was fixed by the previous commit.
The output of test-data/opt-shwordsplit1.zsh on zsh 5.7 is:
.
1..2
## opt-shwordsplit1
# BUFFER=vim
not ok 1 - [1,7] «$EDITOR» - expected (1 7 "function"), observed (1 7 "unknown-token"). # TODO "issue
ok 2 - cardinality check # SKIP cardinality check disabled whilst regular test points are expected to fail
On zsh 5.0.8, tap_escape() choked when called on the arguments argv=('[1,7]'
'«vim»'). This patch fixes that.
As you may have noticed, under zsh 5.7 the diagnostic message of test point 1
is truncated. That'll be fixed in the next commit.
The escaped caret was taken for a negated character class. This caused test-data/arith1.zsh
to XPass: the arithmetic expansion was consumed by the 'while' loop.
This is not perfect: we don't try to detect cases such as «$((ls); (ls))»,
which look like arithmetic expansions but are in fact command substitutions.
Fixes part of #607.
Introduces #704.
The cardinality check shall —
- if the test sets \$expected_mismatch, be XFail;
- elif any test points is XFail, be skipped;
- else, be expected to pass.
To test this, change «6 * 9» to «6 + 9» in test-data/arith1.zsh that
will be added in the after-next (grandchild) commit.
Note that there will be no zsh 5.3.2; zsh 5.3.1 will be followed
by 5.4. There might be 5.4-test-1 pre-releases, though.
* upstream/pr/433:
driver: Improve comment about ^r pattern match bug
driver: Adjust zsh version for probing for pattern match bug
README: Fix FAQ entry about isearch highlighting
Merge remote-tracking branch 'upstream/pr/395'
* upstream/pr/395:
tests: Add a regression test for issue #392 (aliases beginning with a '+' are lost).
tests: Move some code in preparation for next commit. No functional change.
driver: Don't undefine aliases that begin with a '+', to workaround an upstream bug.
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.
Daniel Shahaf