You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
up-line-or-beginning-search positions the cursor at the end of the line. To allow searching from the prefix of where the cursor was when starting the search, it saves the cursor the first time it is called and then checks if the last widget was up-line-or-beginning-search and if so, restores the cursor.
when the command starts with 'man', then for some reason fast-syntax-highlighting runs the widget -fast-whatis-chroma-callback. This ruins the above check. Now, the cursor is not set to where the search started from, but instead it is at the end of the line, meaning that now the search seems to be stuck (as no other line in history starts with the line of some man page).
Steps to reproduce
I'm not sure how to reproduce in a vanilla environment as I don't know how to recreate the call to -fast-whatis-chroma-callback it seems like it is sometimes called when a line beginning with 'man' is encountered and sometimes not (if I press ctrl-c when the line is stuck on 'man foo', then the next it cycles past 'man foo' and is stuck in the following occurence of man in the history)
Expected behavior
I don't want up-line-or-beginning-search to get "stuck". It seems like invoking zle widgets from some function is not right.
This behavior also occurs on my device.
I don't currently have the energy to investigate the mechanism behind this issue, so I opted for an ugly workaround to temporarily mitigate it.
If you're also troubled by the same issue, consider executing the following after f-sy-h has finished loading:
FAST_HIGHLIGHT[chroma-man]=''
This will break the highlighting behavior for man, but up-line-or-beginning-search will no longer freeze.
Describe the bug
up-line-or-beginning-search positions the cursor at the end of the line. To allow searching from the prefix of where the cursor was when starting the search, it saves the cursor the first time it is called and then checks if the last widget was up-line-or-beginning-search and if so, restores the cursor.
when the command starts with 'man', then for some reason fast-syntax-highlighting runs the widget -fast-whatis-chroma-callback. This ruins the above check. Now, the cursor is not set to where the search started from, but instead it is at the end of the line, meaning that now the search seems to be stuck (as no other line in history starts with the line of some man page).
Steps to reproduce
I'm not sure how to reproduce in a vanilla environment as I don't know how to recreate the call to -fast-whatis-chroma-callback it seems like it is sometimes called when a line beginning with 'man' is encountered and sometimes not (if I press ctrl-c when the line is stuck on 'man foo', then the next it cycles past 'man foo' and is stuck in the following occurence of man in the history)
Expected behavior
I don't want up-line-or-beginning-search to get "stuck". It seems like invoking zle widgets from some function is not right.
Screenshots and recordings
No response
Operating System & Version
linux-gnu | ubuntu | x86_64 | x86_64 | x86_64 x86_64
Zsh version
zsh 5.8.1 (x86_64-ubuntu-linux-gnu)
Terminal emulator
xterm-256color
If using WSL on Windows, which version of WSL
None
Additional context
No response
The text was updated successfully, but these errors were encountered: