movePrimaryCursorIntoVisibleRange lags behind 1 screen, possible race condition?

[zpencer]

Context:

By default with 'emacs-mcx.strictEmacsMove': false:

• When scrolling down 1 page (ScrollUpCommand, or page down), the cursor is moved to the bottom of the visible range.
• When scrolling up 1 page (ScrollDownCommand, or page up), the cursor is moved to the top of the visible range.

When strictEmacsMove is set the behavior is supposed to be flipped. When scrolling down a page, the cursor is at the top of the screen, and vice versa.

Problem:

I notice that when strictEmacsMove is set, movePrimaryCursorIntoVisibleRange seems to think the visibleRange is always 1 page behind. So if I begin with lines 0 to 50 visible, and then I scroll down 1 page so that lines 51-100 are visible, I have debug statements inside movePrimaryCursorIntoVisibleRange that show visibleRange contains values that claim lines 0-50 are visible. If I move down another page so that lines 101-150 are visible, then visibleRange claims lines 51-100 are visible.

This results in the cursor being put in the wrong place after each scroll up / down command.

Theory:

https://github.com/microsoft/vscode/issues/157194 suggests that TextEditor.visibleRanges is not atomically updated. I tested this theory by adding a delay, so ScollUpCommand looks something like this, and it worked as expected. This seems to support the theory that there's some sort of race condition when reading visibleRanges

function delay(ms: number): Promise<void> {
  return new Promise(x => { setTimeout(x, ms});
}

vscode.commands.executeCommand<void>(...).then(()  => delay(200))
.then(() => movePrimaryCursorIntoVisibleRange(textEditor, isInMarkMode, this.emacsController)