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.
When writing an expected-to-fail test case, the cardinality of $region_highlight
at the time the test is written may differ from the cardinality it will have
once the bug is fixed. For example, with issue #641.5, the current highlighting
is ['nice', 'x=y', 'y', 'ls'] — four elements — but the correct highlighting
would have three elements: ['nice', 'x=y', 'ls']. There is no point in reporting
a separate test failure for the cardinality check in this case, nor for 'ls' being
highlighted as 'command' rather than 'default'.
At the same time, in other cases the current and correct highlighting may have the
same number of elements (for example, this would be the case for a hypothetical
"the command word is highlighted as an alias rather than a function" bug). Thus,
the previous commit, q.v..
than consider it an expected failure.
With this change, if $expected_region_highlight and $region_highlight
coincidentally have the same number of elements, the test won't be considered
to fail.
This is useful in conjunction with the next commit, q.v..
At this time, no tests set $expected_mismatch explicitly. However, the
commit after next (this commit's grandchild) will add a test that will
set $expected_mismatch implicitly, using the functionality in the next
commit (this commit's child).
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.
