Ensure that cursor state change is always emitted upon restoring state #203451
Conversation
|
Thanks for your analysis and bug report! I think the bug fix is at the wrong location though. The event is correct, it should only fire when it changes. When the default value is (1,1) and the workbench restores the value to (1,1), no event should be fired. However, the |
|
@hediet Thank you for reviewing my changes and providing feedback! I have adjusted my implementation according to the information provided. This time, I explicitly added In cases where the cursor is not at the default position after state restoration, |
|
Much nicer change! Thank you! |
3 participants
Fixes #203345
It seems that the distinction between cases where the scrollbar background appears and where it does not lies in whether onCursorStateChanged is called or not. When a file is opened, restoreCursorState fires events that initialize the cursor state, and _emitStateChangedIfNecessary determines whether the
CursorStateChangedEventshould be fired by comparing the previous and current cursor states. However, it appears that the default value for the cursor position in a newly opened view is (1,1), which results in theCursorStateChangedEventnot being fired if the cursor position after restoration is also (1,1) – the cursor positioned before the first character on the first line. Without this event, certain parts of DecorationsOverviewRuler do not initialize properly, leading to the problem I linked above.To address this, I've ensured that cursor events are emitted if they were caused by the
restoreState.