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
Hey guys! I'm a dev on the vscode team, and recently have worked a bit with implementing a configurable delay for the wordhighlighter, which gives a more responsive editor-feel when turned down to 0. This next insiders we will be turning the delay to 0 by default, and rolling that setting change out to stable upon the next release.
During testing, one of our team members found an issue with words flickering while the delay was reduced to 0 and using the vim extension. I found the reason to be the explicit use of vscode.commands.executeCommand('editor.action.wordHighlight.trigger')at this point, which in turn will call on a restoreViewState() on our side in core. Unfortunately, there's no way to avoid the visual flickering with the current logic of the vim extension combined with the new 0 delay setting. As a patch, I've made it such that the explicit triggers of the word highlighter will always bring along the 250ms delay that had previously been built into the feature (ie, if you're using vim currently, you won't be able to benefit from the more responsive highlighting).
Additionally, we now allow cursor change events with the source api to trigger highlights. With this change in particular, there is no longer a need to explicitly trigger a wordhighlight to have occurrences highlighted, the listener will correctly pick up these position changes and highlight accordingly. This was tested by commenting out the contents of this restore view state fn, effectively making the highlight command a noop.
Hopefully this is enough information to be able to make any necessary changes! Of course, feel free to reach out to me directly and I'll keep an eye on this issue as well. Thanks!
The text was updated successfully, but these errors were encountered:
Hey guys! I'm a dev on the vscode team, and recently have worked a bit with implementing a configurable delay for the wordhighlighter, which gives a more responsive editor-feel when turned down to 0. This next insiders we will be turning the delay to 0 by default, and rolling that setting change out to stable upon the next release.
PR for the change: microsoft/vscode#240321
During testing, one of our team members found an issue with words flickering while the delay was reduced to 0 and using the vim extension. I found the reason to be the explicit use of
vscode.commands.executeCommand('editor.action.wordHighlight.trigger')
at this point, which in turn will call on arestoreViewState()
on our side in core. Unfortunately, there's no way to avoid the visual flickering with the current logic of the vim extension combined with the new 0 delay setting. As a patch, I've made it such that the explicit triggers of the word highlighter will always bring along the 250ms delay that had previously been built into the feature (ie, if you're using vim currently, you won't be able to benefit from the more responsive highlighting).Additionally, we now allow cursor change events with the source
api
to trigger highlights. With this change in particular, there is no longer a need to explicitly trigger a wordhighlight to have occurrences highlighted, the listener will correctly pick up these position changes and highlight accordingly. This was tested by commenting out the contents of this restore view state fn, effectively making the highlight command a noop.Hopefully this is enough information to be able to make any necessary changes! Of course, feel free to reach out to me directly and I'll keep an eye on this issue as well. Thanks!
The text was updated successfully, but these errors were encountered: