In «a="b=c"; $a», the '=' sign in the expansion of $a is not active.
Therefore, prevent the expansion of $a from being considered an
assignment. Update test expectations accordingly.
As a side effect, this prevents line 836 from firing for the cases in
these two tests, thereby fixing the double $region_highlight addition
(see log message of the previous commit). That leaves the line 966
addition. However, the double addition remains a latent bug (see
discussion in PR #684).
Current test failures:
Running test main
# parameter-value-contains-command-position1
1..2
ok 1 - [1,7] «$foobar»
not ok 2 - have 1 expectations and 2 region_highlight entries: «expected_region_highlight=( '1 7 assign' )» «region_highlight=( '0 7 assign' '0 7 assign' )»
# parameter-value-contains-command-position2
1..2
ok 1 - [1,2] «$y»
not ok 2 - have 1 expectations and 2 region_highlight entries: «expected_region_highlight=( '1 2 assign' )» «region_highlight=( '0 2 assign' '0 2 assign' )»
They fail as follows:
ZSH_PATCHLEVEL=debian/5.7.1-1
Running test brackets
Running test main
# parameter-value-contains-command-position1
1..2
not ok 1 - [1,7] «$foobar» - expected (1 7 "assign"), observed (1 7 "unknown-token").
ok 2 - cardinality check
# parameter-value-contains-command-position2
1..2
not ok 1 - [1,2] «$y» - expected (1 2 "assign"), observed (1 2 "unknown-token").
ok 2 - cardinality check
(The "unknown-token" was printed by the `_zsh_highlight_main_add_region_highlight`
call on line 967, after the loop.)
Before the parent commit, they behaved as follows (note the "BUG:" and
"Bail out!" on the first one — that's issue #670.2):
ZSH_PATCHLEVEL=debian/5.7.1-1
# parameter-value-contains-command-position1
1..2
ok 1 - [1,7] «$foobar» - # TODO "issue #670"
not ok 2 - have 1 expectations and 6 region_highlight entries: «expected_region_highlight=( '1 7 assign "issue ♯670"' )» «region_highlight=( '0 7 assign' '2 7 default' '2 7 command-substitution-unquoted'
zsh-syntax-highlighting: BUG: _zsh_highlight_highlighter_main_paint: start(2) >= end(2)
Bail out! On './highlighters/main/test-data/parameter-value-contains-command-position2.zsh': output on stderr
# parameter-value-contains-command-position2
1..2
ok 1 - [1,2] «$y» - # TODO "issue #670"
ok 2 - cardinality check
We cannot now for sure whether the flag is misspelled or simply unknown to us,
so err on the side of caution. This fixes an unreleased regression. Fixes#658.
Issue #641 was originally filed about this problem, but is left open to track
further enhancements.
$last_alias isn't needed; there's no reason to treat loops of length 2
(alias a=b b=a) differently to loops of length 1 (alias a=a), length 3
(alias a=b b=c c=a), or length N.
The «(( $+seen_alias[$arg] ))» check is redundant as of the last commit:
the enclosing condition ensures that $res is "alias", which implies that
«(( $+seen_alias[$arg] ))» is false.
occurred on zsh-5.0.7 and older but I don't have zsh-5.0.7 handy to test
on.)
Evidently, the issue was due to elision.
This addresses #665.0 and #665.5.
The test point is XPASSing, which makes CI red. As a duct tape measure to turn
CI green again, update the test expectations to make it XFAIL. The hacky part
is that the expectation set by this commit will never be met; the test point
will never XPASS now until its expectations are changed again.
Issue #623 remains open to track setting the test expectation to the correct
value (i.e., make the test XFAIL in a manner that _will_ XPASS if the bug is
fixed; in other words, pay off the technical debt created by this commit).
Issue #616 remains open to fix the actual bug.
