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:

microsoft/vscode#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)

[zpencer]

FWIW I discovered that the vscode command editorScroll now has a recealCursor argument that makes the cursor behave in a way that is the same as emacs. However, this alone is not enough to replace movePrimaryCursorIntoVisibleRange, because that function also has some special handling for mark mode.

I'm not sure what's the right way to fix this issue, assuming it's not just something strange about my vscode instance in particular.