Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
5
contributors
Commits on Sep 22, 2024
Commits on Sep 29, 2024
-
-
lsp: Implement a
${defaultBuildDir}config variableUnless esbonio finds a `sphinx-build` command to use from the user's config it will attempt to guess something reasonable. During this process it generates a default build directory to use, in a subfolder of `platformdirs.user_cache_dir()` so that it does not interfere with the user's files. Up until now, the moment a user sets their own `sphinx-build` command this behavior is lost, which can lead to issues on some systems (see #865). This commit introduces a `${defaultBuildDir}` placeholder value that the user can use to provide their own build flags, while maintaining the default choice of build dir provided by esbonio.
-
-
-
-
-
lsp: Ensure filepaths are properly escaped
Backslashes in Windows filepaths can cause issues ```python >>> import re >>> VARIABLE = re.compile(r"\$\{(\w+)\}") >>> VARIABLE.sub('\\path\\to\\cache', '${defaultBuildDir}/doctrees') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python3.12/re/__init__.py", line 334, in _compile_template return _sre.template(pattern, _parser.parse_template(repl, pattern)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.12/re/_parser.py", line 1075, in parse_template raise s.error('bad escape %s' % this, len(this)) from None re.error: bad escape \p at position 0 ``` Calling `re.escape` on the replacement ensures that characters like backslashes are escaped correctly ```python >>> VARIABLE.sub(re.escape('\\path\\to\\cache'), '${defaultBuildDir}/doctrees') '\\path\\to\\cache/doctrees' >>> ``` -
lsp: Create a placeholder for a client at the given scope
When `manager.get_client` is called many times in quick succession (such as on server restart with N files open) this can fool the `SphinxManager` into creating multiple client instances for a given configuration scope. By storing a ``None`` at the relevant scope we allow the SphinxManager to detect that the scope has already been handled, preventing the spawning of duplicated client instances. This should, finally, fix the flaky test issue (#859)
-
code: Compare the string representation of URIs
For some reason, the object representation of the same URI is not stable leading to synchronised scrolling breaking after scrolling the preview window. Instead, compare the string representation of the uris which should work around the differences that should not matter.
-
sphinx-agent: Rewrite internal links
As part of its initial setup, the injected `webview.js` script now rewrites any `a.internal` links to include the port number of the current websocket connection. This ensures that as the user navigates by clicking on links on the page the websocket connection to the language server is preserved. Also by doing an initial scroll sync on page load, this ensures that the editor is kept in sync with the change! There is a chance for this to be a bit flaky as this in direct conflict with the initial sync an editor might want to make if it initiates the preview of a page. By introducing a small delay on the sync made by the webview, we are relying on the editor winning the race and getting its message in first... I'm sure that will never cause an issue in the future!
Commits on Oct 7, 2024
-
-
code: Derive CSP string from
asExternalUriIn addition to running the preview uri from the server through `vscode.env.asExternalUri` we need to make sure that the CSP for the embedded iframe is given the correct origin.
-
-
-
sphinx-agent: Take entire websocket URL from query parameter
The injected `webview.js` script now assumes that the `ws` query parameter contains the entire URI to use when creating the websocket connection
-
Commits on Oct 9, 2024
-
build(deps-dev): bump ovsx from 0.9.4 to 0.9.5 in /code
Bumps [ovsx](https://github.com/eclipse/openvsx/tree/HEAD/cli) from 0.9.4 to 0.9.5. - [Release notes](https://github.com/eclipse/openvsx/releases) - [Changelog](https://github.com/eclipse/openvsx/blob/master/cli/CHANGELOG.md) - [Commits](https://github.com/eclipse/openvsx/commits/v0.9.5/cli) --- updated-dependencies: - dependency-name: ovsx dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
-
[pre-commit.ci] pre-commit autoupdate
updates: - [github.com/pre-commit/pre-commit-hooks: v4.6.0 → v5.0.0](pre-commit/pre-commit-hooks@v4.6.0...v5.0.0) - [github.com/astral-sh/ruff-pre-commit: v0.6.5 → v0.6.9](astral-sh/ruff-pre-commit@v0.6.5...v0.6.9)
-
build(deps-dev): bump esbuild from 0.23.1 to 0.24.0 in /code
Bumps [esbuild](https://github.com/evanw/esbuild) from 0.23.1 to 0.24.0. - [Release notes](https://github.com/evanw/esbuild/releases) - [Changelog](https://github.com/evanw/esbuild/blob/main/CHANGELOG.md) - [Commits](evanw/esbuild@v0.23.1...v0.24.0) --- updated-dependencies: - dependency-name: esbuild dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Commits on Oct 13, 2024
-
build(deps-dev): bump @vscode/vsce from 3.1.0 to 3.1.1 in /code
Bumps [@vscode/vsce](https://github.com/Microsoft/vsce) from 3.1.0 to 3.1.1. - [Release notes](https://github.com/Microsoft/vsce/releases) - [Commits](microsoft/vscode-vsce@v3.1.0...v3.1.1) --- updated-dependencies: - dependency-name: "@vscode/vsce" dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Commits on Oct 16, 2024
-
-
sphinx-agent: Suppress and report extension errors
The sphinx-agent will no longer crash if the configured environment is missing an extension. Instead the error is suppressed and the agent will attempt to report it to the user as a diagnostic However, the diagnostic will only work if the extensions are declared in `conf.py` using the "standard" Sphinx format i.e. ```python extensions = [ 'a', 'b', ... ] ``` -
Commits on Oct 20, 2024
-
-
-
lsp: Use fallback env when possible
If a client provides the `esbonio.sphinx.fallbackEnv`, repurpose the server's Python interpreter to launch the Sphinx agent.
-
Most runs conclude on the order 5min +/- 2min, so if we hit the 20min mark chances are something has hung.
-
sphinx-agent: Expose the AST for
conf.pyvia an attributeThis allows us to parse the file once in a central location
-
sphinx-agent: Implement a fallback html_theme
The sphinx agent can now handle the case where the requested `html_theme` is not available in the environment by suppressing the raised error, overriding the value of `html_theme` and attempting to run `Sphinx.__init__` again.
-
-
-
Commits on Oct 21, 2024
Commits on Dec 1, 2024
-
-
lsp: Use
concurrent.futures.Futureinstead ofasyncio.Futurepygls in `v2.0a2` switched from using the low-level asyncio APIs to using the high-level one and surprisingly, this broke `esbonio`. The server would start ok, but wouldn't launch Sphinx processes, the preview command did nothing, it wouldn't even produce any log messages! That is, until the user changed a configuration setting. After changing a setting - any setting, the server suddenly springs into life, logs, previews, sphinx processes all of them would start working as if nothing was wrong. I eventually managed to figure out that the callbacks registered by the configuration system on the server's `ready` future were never being called. ``` self.server.ready.add_done_callback(self._notify_subscriptions) ``` By why would changing the asyncio API in use break these callbacks?! After spending some time with the debugger I eventually spotted the culprit ``` >>> asyncio.get_running_loop() <_UnixSelectorEventLoop running=True closed=False debug=False> >>> self.server.ready._loop <_UnixSelectorEventLoop running=False closed=False debug=False> ``` The server's `ready` future was using a different event loop and because the event loop is not running, when the future is resolved, the callbacks were never scheduled! While I cannot explain why this was not an issue before, I can explain why it is an issue now. The `ready` future is created in the constructor of the `EsbonioLanguageServer` class - before any event loop has been created and so it uses a new one based on the current event loop policy[1][2]. Unfortunately, when pygls later starts its main loop by calling `asyncio.run()` it creates a new event loop, orphaning the `ready` future in its unused event loop[3] Since we don't need to use the `ready` future asynchronously, the simplest fix is to convert it to future from the `concurrent.futures` module, removing the need for an event loop completely. [1]: https://github.com/python/cpython/blob/307c63358681d669ae39e5ecd814bded4a93443a/Lib/asyncio/futures.py#L79 [2]: https://github.com/python/cpython/blob/307c63358681d669ae39e5ecd814bded4a93443a/Lib/asyncio/events.py#L791 [3]: https://github.com/python/cpython/blob/307c63358681d669ae39e5ecd814bded4a93443a/Lib/asyncio/runners.py#L146
-
-
- Use new `pygls.io_` infrastructure - Use new `websockets.asyncio` API
There are no files selected for viewing