Do not highlight in isearch widgets #257
Conversation
As long as zle_highlight for the isearch region can't be applied properly *after* zsh-syntax-highlighting is done it does not make sense to apply any highlighting while isearch is active. Otherwise its almost impossible to see the matched area.
|
Can you describe how to reproduce the problem, starting from Does this depend on some of your other PRs? I guess it might depend on the second part of #255. (and on having defined a |
|
One example is this: then type This results in 3 characters in the beginning behing highlighted in green, because |
|
Thanks, I can reproduce this. As in #259 (comment): if it's possible to write a test case for this it'd be great, but I realize that might be non-trivial.
For future reference, the way to do this would be to mimic the handling of zle_highlight[region] and zle_highlight[paste] in the driver. I think you can use … and I guess you might want to set |
I looked into the zsh source, but sadly the beginning and end of the underlined segment are not exposed in the environment at all. |
|
As in #259, this patch is also useless if In a clean |
Expose them to widgets, then? YANK_ACTIVE was only added in 5.1.1, specifically because z-sy-h needed it... |
Is there some other thing we can do? For example, could we do |
|
I can no longer reproduce this. Could you please provide reproduction instructions again? The instructions above don't reproduce the problem for me with current HEAD, even if I define a In the reproduction recipe, what widget does |
|
I can still reproduce the issue using the same instructions. By the way: The fact that |
|
So can I; I missed that I had to type |
|
Status:
|
|
About the workaround for zsh <5.3: If |
Old version of zsh don't expose ISEARCH_ACTIVE. Therefore we are unable to re-apply zle_highlight on top and it is impossible to see the underlined area. 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 zsh-users#257.
|
For zsh that includes zsh-users/zsh@cbc44bd (workers/38145, due to be released in zsh-5.3), this was fixed by #283 / 79e4d3d. A different fix is needed for older zsh. |
Old version of zsh don't expose ISEARCH_ACTIVE. Therefore we are unable to re-apply zle_highlight on top and it is impossible to see the underlined area. 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 zsh-users#257.
Old version of zsh don't expose ISEARCH_ACTIVE. Therefore we are unable to re-apply zle_highlight on top and it is impossible to see the underlined area. 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 zsh-users#257.
Old version of zsh don't expose ISEARCH_ACTIVE. Therefore we are unable to re-apply zle_highlight on top and it is impossible to see the underlined area. 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 zsh-users#257.
Old versions of zsh don't expose ISEARCH_ACTIVE. Therefore we are unable to re-apply zle_highlight on top and it is impossible to see the underlined area. 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 zsh-users#257.
Old versions of zsh don't expose ISEARCH_ACTIVE. Therefore we are unable to re-apply zle_highlight on top and it is impossible to see the underlined area. 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 zsh-users#257.
Therefore we are unable to re-apply zle_highlight on top in current zsh versions. Therefore it is impossible to see the underlined matched area. 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 zsh-users#257.
We are unable to re-apply zle_highlight on top in current zsh versions. 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 zsh-users#257.
We are unable to re-apply zle_highlight on top in current zsh versions. 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 zsh-users#257.
We are unable to re-apply zle_highlight on top in current zsh versions. 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 zsh-users#257.
zsh version 5.2 and lower don't support ISEARCHMATCH_ACTIE 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 zsh-users#257.
zsh version 5.2 and lower don't support ISEARCHMATCH_ACTIE 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 zsh-users#257.
zsh version 5.2 and lower don't support ISEARCHMATCH_ACTIE 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 zsh-users#257.
zsh version 5.2 and lower don't support ISEARCHMATCH_ACTIE 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 zsh-users#257.
zsh version 5.2 and lower don't support ISEARCHMATCH_ACTIE 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 zsh-users#257.
zsh version 5.2 and lower don't support ISEARCHMATCH_ACTIE 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 zsh-users#257.
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 zsh-users#257. The FAQ entry presupposes zsh-users#245 will be fixed (in time for the release) too.
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 a8fe22d to be correct. This is part of #261, of which #288 was a spin-off. [i257] #257 (comment)
The parent commit, which merged the feature/redrawhook bug and thereby closed PR #749, also fixed the following issue: Fixes #40. Fixes #90, closes #470. (The latter is a PR for the former.) Fixes #150, closes #151, closes #160. (The latter two are PR's for the first one.) The related issue #183 appears to have been fixed in master. For #150, a different fix for older versions of zsh was considered but has not been implemented. Issue #154 was fixed in xsel(1) in 2017. The parent commit probably fixed that issue for pre-2017 xsel(1). Is #245, #356, and #749. Fixes #245 (redrawhook umbrella issue). Does not reintroduce #257 (comment). Does not reintroduce #259 (comment) Closes #281 as obsolete. Fixes #295. Fixes #324. Fixes #375. Fixes #377. Closes #421 as obsolete. Fixes #520. Unblocks #536 (already milestoned). Fixes #632. Unblocks #635. Milestoned. Unblocks #688. Milestoned. Unblocks administrative issue #655 (already milestoned). (The above is copied from #749 (comment), but repeated here for the sake of github's commit-to-issue linking magic.)
As long as zle_highlight for the isearch region can't be applied
properly after zsh-syntax-highlighting is done it does not make
sense to apply any highlighting while isearch is active.
Otherwise its almost impossible to see the matched area.