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.
This patch causes a behaviour difference in the [i257] scenario:
- Before this change, the zle_highlight[isearch] is applied and z-sy-h's
highlighting isn't.
- With this change, both zle_highlight[isearch] and z-sy-h's
highlighting are applied, so «echo foo» renders the first word in green
underline (fg=green from ZSH_HIGHLIGHT_STYLES[builtin], underline from
zle_highlight[isearch]).
This patch causes the presuppositional FAQ entry added in
a8fe22d422 to be correct.
This is part of #261, of which #288 was a spin-off.
[i257] https://github.com/zsh-users/zsh-syntax-highlighting/pull/257#issuecomment-168394665
* danielsh/m0vie-i288-v2:
driver: Don't highlight in isearch
driver: Always bind zle-line-finish and use it instead of accept-*
driver: Widget binding: Support binding incomplete/nonexistent widgets
zsh version 5.2 and lower don't support ISEARCHMATCH_ACTIVE and
we are unable to re-apply zle_highlight on top. Therefore it is
impossible to see the underlined matched area.
Since that information is more important, completely disable
highlighting in isearch in that case.
To do that, we need to make sure we are actually called when
something changes in isearch.
Trumps #257.
The FAQ entry presupposes #245 will be fixed (in time for the release) too.
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.
Merge remote-tracking branch 'danielshahaf/i267-linewise-region-v1'
* danielsh/i267-linewise-region-v1:
tests: Add a regression test for issue #267, concerning highlighting a vi linewise region.
Support linewise region.
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.
Instead, use the %N prompt expando, as suggested by Bart in users/21637.
Avoid the `print -P %N` syntax to save a fork on Cygwin, at the expense
of not supporting zsh's from 2001 through c. 2004 vintages.
Fixes#338.
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.
