VSCode: Synchronized scrolling not working anymore

[decimad]

Expected behavior

I expect synchronized scroll between source and preview to work.

Actual behavior

After updating VScode last week, synchronized scrolling broke (for a short time before it even worked in external windows, which was magnificient).
Additionally, the preview control seems to exceed it's paren't draw area, so that I get two levels of scroll bars:

I could not find a setting that would switch on/off synchronized scrolling.

Log output

No response

(Optional) Settings from conf.py

No response

[alcarney]

Is it just the syncronised scrolling that broke? Or are other preview features like the live updates broken too?

As a blind guess perhaps you've been bitten by #779? The only major change recently is how esbonio manages the underlying Sphinx process, so I would be surprised if the issue was in the preview code itself (ignoring double scroll bars for the moment)

To help debug this, could you set esbonio.logging.level to debug and share the log output from the Esbonio output channel?

[decimad]

Hello, thank you for the quick response!

I'm now really unsure about what really happened. I had a working setup until last week and then something happened without my intervention so that the preview window would only show "Loading ... " with an animated progressbar.

Then I switched between Release and Pre-Release and the only thing that still works, producing the screenshot I posted, is the Release-version. But I can't remember ever actively switching to Pre-Release before, so I'm not sure if I have always been on Pre-Release and it broke, or the Release broke due to some Vscode change.

The trace mainly contains periodic "workspace/diagnostic" messages. I'm currently trying to set the build command manually, as was proposed by someone else, because my project is not at the workspace root. But I have never done that and am running into errors because I made some mistake specifying the command.

[alcarney]

The Release version does not support sync scrolling so it sounds like you were using the Pre-Release version before.

so that the preview window would only show "Loading ... " with an animated progressbar.

Sometimes that's because there's no build files yet for it to preview and you need to give the server a "kick" by editing and saving some file in the project. (I need to get around to fixing that! 😅) Otherwise that generally means the sphinx setup is broken in some way...

The trace mainly contains periodic "workspace/diagnostic" messages.

That sounds like the esbonio.trace.server option is set to something other than `off``? That should stop the server's log messages from being washed away.

If you've updated to the latest pre-release (0.93.1), then you will likely have to set the command manually (e.g. esbonio.sphinx.buildCommand = ["sphinx-build", "-M", "html", "html/_build"]) as it changed the way project discovery works.

But I have never done that and am running into errors because I made some mistake specifying the command.

Feel free to share an error messages you run into :)

[decimad]

Hey, I'm currently bypassing the nested directory problem, using your build command and then receive

"Error: at least 3 arguments (builder, source dir, build-dir)"
(Additionally: Running Sphinx v7.1.2)

I get the feeling I'm doing something very stupid here...

EDIT: I got him to create an output dir, however it stays pretty empty, contains doctree and html folder. However no generated html files.

EDIT2: It basically stops after [autosummary], where my build on the command line will proceed to produce the html output.

[alcarney]

Nope, I'm the one doing something stupid 🤦 Command should be ["sphinx-build", "-M", "html", "docs", "docs/_build"]

I got him to create an output dir, however it stays pretty empty, contains doctree and html folder. However no generated html files.

That sounds promising, you still likely need to give it a "kick" though - try editing and saving one of the files in your project 🤞

[decimad]

Okay, I tried editing and saving some of the files that were mentionend, to no avail. It seems to do something, but then get stuck somehow.

That's my command now: "esbonio.sphinx.buildCommand": [ "sphinx-build", "-M", "html", ".", "build" ]

When restarting the server, it will mention the autosummary plugin and then exit with code 0 (edit: that's me restarting the server), and that's it. Without autosummary it will just state "Running Sphinx v7.1.2" in the Esbonio output, with nothing more happening.

[decimad]

"esbonio.sphinx.buildCommand": [ "C:\\Users\\foo\\AppData\\Local\\Programs\\Python\\python38\\scripts\\sphinx-build.exe", "M", "html", ".", "build" ],

results in a Json-Error that "source directory X cannot be found", where X is the absolute path to the sphinx-build. Is that supposed to be?

Edit: When correctly specifying "-M" instead of "M", then main.py errs out with "unrecognized arguments: -M". The same command from the prompt works flawlessly :(

[decimad]

Okay, I tried various pre-release versions and "v0.91.0 (pre-release)" is the last one that seems to work (even with scroll lock). This one will actually create the html files after starting the server and saving an arbitrary source file.

Edit: Unfortunately the extension's changelog does not mention "v0.91.0", so I'm not sure if the entry "v0.92.0" compiles the changes since "v0.11.0"... or if they are the changes since "v0.91.0".

Edit #2: Vscode marks "esbonio.sphinx.buildCommand" as a known setting in "v0.91.0", so I think the compilation theory holds. Maybe reducing the scope to the delta between "v0.91.0" and "v0.92.0" helps.

[decimad]

Feedback on the next day: I got the most recent build working with a .venv.
However, I can't navigate references anymore and there are no auto-completions. I tried esbonio standalone and via restructuredtext.

Edit: New finding - if the target python environment has the esbonio package installed, then it must be recent enough. It seems a simple install esbonio without specific version will install a really old one. If it is installed and the version does not match, then the Preview will also stall in "Loading" state. Given that, intellisense still seems to be dyscunctional or its presence was contributed by a different vscode extension. Also the scroll lock seems to be lost after some time.

[alcarney]

Thanks for persevering with this!

I think at this point it might be useful to try and clarify a few things. Esbonio is composed of two main components, a language server written in Python, and a VSCode extension. Both of these components currently have a release version and a pre-release version.

• Release versions: VSCode v0.11.0, Python: v0.16.4
• Pre-release versions: VSCode v0.91.0+, Python v1.0.0b2

Over the past year or so, the pre-release versions have morphed into a complete rewrite of the respective components, so while I would argue that they are better than the release versions, they're not yet feature complete.

New finding - if the target python environment has the esbonio package installed, then it must be recent enough. It seems a simple install esbonio without specific version will install a really old one.

On that note, the pre-release version of the VSCode extension bundles the server component, so it's not necessary to install esbonio into a local environment anymore.

If it is installed and the version does not match, then the Preview will also stall in "Loading" state.

That's good to know! It's possible that the old version conflicts with the way the new version injects itself into the environment - at the very least the extension should advise you to remove it.

Given that, intellisense still seems to be dyscunctional or its presence was contributed by a different vscode extension.

One of the (many) features missing in the pre-release version is intellisense. With v0.93.1 of the VSCode extension I would only expect basic directive name completion to be working (e.g. .. toctree::)

Also the scroll lock seems to be lost after some time.

Interesting... I don't suppose you're running into #646? If you could share some of the debug logs (esbonio.logging.level = debug) from the Esbonio output channel it would really help diagnose the issues you are seeing.

[decimad]

Hi there, thank you for responding!

I will try to find something noteworthy in the log tomorrow regarding the loss of lock (reminds me of PLL, heh).

I think I notice a different behavior in the lock mechanism now. The "old" version had an issue where just saving the document moved both the source view as well as the preview view, but the lock felt "smooth".
The new version fixed the save-issue, however it seems when scrolling, the lock is now more "stuttery". Hard to describe. I'm really unsure whether not the move-on-save was preferrable.
Am I hallucinating this?

Greetings and thank you very much!

[alcarney]

Not sure which "old" version you are referring to sorry, as only the pre-release has offered synchronised scrolling, and the feature itself has not really changed since it first came out.

However, I definitely know what you mean by it being "stuttery", currently there are relatively few locations on the page where the views are able sync-up (Assuming it still works, the esbonio.preview.showLineMarkers option should highlight them). #786 should hopefully cover what's needed to improve this.

How well the feature works can also depend on your theme, furo for example implements smooth scrolling which seems to improve things. I seem to remember other themes like alabaster being quite jarring....

[decimad]

Hello!
I'm very sorry it took me so long to come back to this issue.

Here are some noteworthy entries from the log when the preview lost track:

Request failed: Request with id "4350" is canceled (-32800).
Request failed: Request with id "4335" is canceled (-32800).
Request failed: Request with id "4329" is canceled (-32800).

I can't tell for sure, if these events are really related though.

[alcarney]

I'm very sorry it took me so long to come back to this issue.

No worries!

I can't tell for sure, if these events are really related though.

I'm not sure either, they're not messages I recognise... were they in the Esbonio channel in the output window?
I'd have expected to see messages that look more like this