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.
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.
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.
_zsh_highlight_add_highlight appends to region_highlight $1 $2 and the
next non-null parameter. If there is no non-null parameter, do nothing,
This is so that highlighters can add a style with fallbacks if the most
specific style is not defined. If none of the applicable styles are
defined, do the right thing and don't add an invalid entry to
region_highlight.
The pattern highlighter doesn't use this function as it'd need too large
of an API change.
- 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
The '--' guard was correct; it was there to guard against arguments belonging
to the syntax «zle widget [ -n num ] [ -Nw ] [ -K keymap ] args».
For example, this affected using <backward-kill-word> over
BUFFER="-w "
CURSOR=3
after
autoload -Uz select-word-style
select-word-style default
zstyle ':zle:backward-kill-word' word-style shell
.
This reverts commit c808d2187a.
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.
It's the widget's caller's responsibility, not ours, to add '--' where due. If
we do it, two instances of '--' might result. (I haven't been able to provoke
this problem.)
If this commit causes problems, the cause would be widget-callers that don't
pass '--' although they should.
All these files should be sourced, not executed; and Debian's lintian complains:
W: zsh-syntax-highlighting: script-not-executable usr/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh
This reverts commit 8e7c26f489.
Currently, after a 'yank', paste highlighting (via $YANK_ACTIVE in zsh 5.1.1)
is applied but other highlighting (e.g., string highlighting when the yanked
text is «"foo» as a new word) is not.
See issue #183 for context.
Conflicts:
zsh-syntax-highlighting.zsh
As explained in #143 (which was a PR for #99), 'yank-pop' only works when the
previous widget has the ZLE_YANK flag, which means wrapping the 'yank' widget
breaks the 'yank-pop' widget (makes it a no-op). However, that is a reason
against wrapping the 'yank' widget, but not against wrapping the 'yank-pop'
widget. Indeed, if 'yank-pop' is wrapped but 'yank' isn't, then yank-pop
functions correctly and updates highlighting properly.
To unbreak yank-pop, either 'yank' should be excluded from wrapping, or one of
the fixes mentioned on issue #183 should be applied.
Sourcing zsh-syntax-highlighting.zsh without FUNCTION_ARGZERO doesn't work (for
reasons unrelated to this branch), but now errors out gracefully. The failure mode
before this branch was:
zsh-syntax-highlighting: highlighters directory '/usr/local/bin/highlighters' not found.
where /usr/local/bin is dirname() of the zsh binary.
See issue #137. A reproduction recipe for testing this change:
$ zsh -f
% bindkey -e
% source <the script from http://www.zsh.org/mla/users/2014/msg00321.html users/18584>
% source zsh-syntax-highlighting.zsh
% echo foo
% echo bar
% <^R>echo<^R>
This finds the 'echo foo' with this change but not without it.
