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
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.
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.
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.
- Extract duplicated code into a new function.
This makes it easier to add support for other entries in the
future, that cannot be accessed in the current version of zsh
(isearch, suffix).
- Make decision logic more comprehensible.
- Respect deliberately empty entries in zle_highlight.
Don't force the default value when the user deliberately sets
an entry in zle_highlight to the empty string.
For example
zle_highligh(paste:)
to disable paste highlighting completely.
Skipping when $cur_widgets == user:$cur_widget was introduced
with 776453cb5b. However there
are cases where this is not just an 'already rebound' event, but
simply a normal widget whose function name happens to be identical
to its widget name.
Example:
expand-absolute-path is a widget whose function name is also
expand-absolute-path. No reason why this should be ignored.
Another example:
edit-command-line
Just because a widget starts with _ does not mean it should be
skipped when rebinding. The only reason widgets need to be skipped
is when their function name start with _zsh_highlight_widget*,
which is checked later.
Example:
_expand_alias (^Xa) needs to be wrapped.
The exclusion of _* was introduced in 186d80054a
to fix#65, but it is not needed. The relevant exclusion of
_zsh_highlight_widget* is already enough due to the case statement.
m0viefreak