-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
workaround for PAT_STATIC bug in zsh #415
Conversation
Isn't We should probably determine and remember this beforehand when sourcing z-sy-h, also for performance reasons. |
@m0vie as soon as I read your comment, I realized you had to be right. I double checked in my plain-vanilla "fake" config and my work-around didn't work. I pushed up a revised version that stores the value and uses that. It's also easier to read, which I like. |
@docwhat Feel free to join us on #zsh-syntax-highlighting on freenode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for putting this together, @docwhat.
Would you be able to revise the PR accordingly? No problem if you can't, just please let me know either way.
README.md
Outdated
or newer. | ||
Yes! | ||
|
||
If you're using `history-incremental-search-backward` (by default bound to <kbd>Ctrl_R</kbd> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious what was the reasoning behind the change of Ctrl_R
to Ctrl+R
. (Not need to revert it — six of one, half a dozen of the other — just curious.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo on my part. :-/
README.md
Outdated
in zsh's emacs keymap) then it works with _zsh version 5.3 and newer_. | ||
|
||
If you're using `history-incremental-pattern-search-backward`, then syntax highlighting works | ||
in _zsh 5.3.2 and newer_ due to [a bug](http://www.zsh.org/mla/workers//2017/msg00034.html). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use the X-Seq links: http://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=40285
Could we qualify the term "bug" to explain it's an upstream (zsh) bug?
Could we reword this to reflect that 5.3.2 is not yet released (and will probably be called 5.4)? I'll update #412 to refer to this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now it describes what the code does...
- Will zsh ever release a 5.3.2?
- If so, would it just include security patches, or would it include this patch to?
- Should I just change the
is-at-least
to 5.4?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(being discussed in the toplevel comments below)
zsh-syntax-highlighting.zsh
Outdated
zsh_highlight__pat_static_bug=f | ||
else | ||
zsh_highlight__pat_static_bug=t | ||
fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As much as I like lisp, I think the code would be overall easier to read if it used only a single representation of booleans. We already both x=false
/x=true
/if $x
and x=0
/x=1
/if (( x ))
[my fault for having two]; I'd rather not introduce a third way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
zsh-syntax-highlighting.zsh
Outdated
@@ -67,7 +76,7 @@ _zsh_highlight() | |||
|
|||
# Remove all highlighting in isearch, so that only the underlining done by zsh itself remains. | |||
# For details see FAQ entry 'Why does syntax highlighting not work while searching history?'. | |||
if [[ $WIDGET == zle-isearch-update ]] && ! (( $+ISEARCHMATCH_ACTIVE )); then | |||
if [[ $WIDGET == zle-isearch-update ]] && ([[ $zsh_highlight__pat_static_bug == t ]] || ! (( $+ISEARCHMATCH_ACTIVE )) ); then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could use a block { … }
rather than a subshell.
Also, I'd like some comment explaining the second conjunct in English: it's hard enough for me to get a mental picture of the behaviour under various zsh versions as the conjunct stands before this patch.
The logic here is "Disabling highlighting during isearch (for reasons explained in README.md) unless zsh is new enough and doesn't have the 5.3.1 bug".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -53,6 +53,15 @@ fi | |||
# Core highlighting update system | |||
# ------------------------------------------------------------------------------------------------- | |||
|
|||
# Use workaround for bug in ZSH? | |||
# zsh-users/zsh@48cadf4 http://www.zsh.org/mla/workers//2017/msg00034.html | |||
autoload -U is-at-least |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's another autoload is-at-least
on line 397 which can be removed now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
ZSH versions less than 5.3.2 (or 5.4) have a bug that prevents `history-incremental-pattern-search-backward` for working correctly (the history stops searching after the first found item). Closes #407
Pulling this out for visibility... The current change has everything you asked for except this... @danielshahaf said:
Right now it describes what the code does...
|
in zsh's emacs keymap) then it works with _zsh version 5.3 and newer_. | ||
|
||
If you're using `history-incremental-pattern-search-backward`, then syntax highlighting works | ||
in _zsh 5.3.2 and newer_ due to [a bug in zsh](http://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=40285). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
history-incremental-search-backward
or history-incremental-pattern-search-backward
doesn't matter, we don't check for that. Its 5.3.2 and newer in all cases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The information in the readme is still wrong. See my comment above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Broke this out as #423
@@ -67,7 +76,9 @@ _zsh_highlight() | |||
|
|||
# Remove all highlighting in isearch, so that only the underlining done by zsh itself remains. | |||
# For details see FAQ entry 'Why does syntax highlighting not work while searching history?'. | |||
if [[ $WIDGET == zle-isearch-update ]] && ! (( $+ISEARCHMATCH_ACTIVE )); then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably add a comment here stating that we must never use any pattern before this line, in order to not break things again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@m0vie At this point it may be easier to ask pws to release a 5.3.2 with your patch (and other stability fixes) included?
@docwhat The next zsh feature release will be 5.4. There may be a 5.3.2 hotfix release before then. In principle, zsh may decide to release a 5.3.1.1, but that's unlikely. And in either of the three cases, we can't be sure whether the release would fix the Now, I won't release z-sy-h with an is-at-least condition that refers to a future zsh release, and people who use zsh from master should use HEAD of master; therefore, I think it doesn't matter what version number we pass to is-at-least, so long as we have a note on #412 to fix it after zsh's release and before z-sy-h's release. Makes sense? |
Just so I understand what my action item is: I should set the Can we push zsh to release 5.3.2 sooner rather than later and release it with that version check (as you mentioned above)? |
@danielshahaf:
Just so I understand what my action item is: I should set the
`is-at-least` check to `5.3.1.1` (as you suggested previously?
My current idea is that it _doesn't matter_ whether the code says `is-at-least 5.3.1.1` or `is-at-least 5.3.2`, since I will wait for the next zsh release — and update the argument to is-at-least accordingly — before releasing z-sy-h. Makes sense?
Can we push zsh to release 5.3.2 sooner rather than later and release it with that version check (as you mentioned above)?
We certainly can. All it takes is for someone to email zsh-workers@ and ask/convince them to do so. :)
|
It's been a while, @danielshahaf -- Is there anything else I need to do with this PR? Or are we still good? |
@movie's patch is |
No apologies necessary! Thanks! |
ZSH versions less than 5.3.2 (or 5.4) have a bug that prevents
history-incremental-pattern-search-backward
for workingcorrectly (the history stops searching after the first found item).
Closes #407