Repository navigation
Separate language support from vscode-R again #1749
Description
I would like to reconsider separating the language-server integration from vscode-R, similar to the old vscode-r-lsp, and eventually make REditorSupport.r an extension pack / umbrella extension.
When vscode-r-lsp was merged into vscode-R in 2.1.0 (#695), languageserver was effectively the standard choice for R language intelligence.
That is no longer the case.
The R editor ecosystem now has several actively developed, independently distributed tools with VS Code extensions:
- Air provides a very fast Rust-based formatter and language server.
- Jarl provides a fast Rust-based linter with diagnostics and automatic fixes.
- Arity provides a full Rust-based language server with completion, hover, go-to-definition/references, rename, diagnostics, semantic tokens, and more.
- Posit's Oak may become another standalone R language server in the future.
In particular, these newer tools are designed around fast static analysis.
Given this ecosystem, it no longer seems ideal for vscode-R itself to own one particular LSP client/runtime combination.
VS Code ecosystems such as Python and Java also separate language support and other tooling into independently maintained extensions, often combined through an extension pack.
A possible long-term structure would be:
REditorSupport.r # extension pack / main entry point
├─ REditorSupport.r-syntax
├─ REditorSupport.r-runtime
└─ REditorSupport.r-lsp # current languageserver-based integration
r-lsp could remain the default language support installed by the pack, while users could disable or replace it with Air, Jarl, Arity, or future alternatives without fighting functionality bundled into the main extension.
The first step could simply be extracting the existing LSP client with minimal behavior changes.
A larger runtime split can be discussed separately.
Activity
jolars commentedon Sep 22, 2026
I think this is a good idea! I am the maintainer of Arity and it would be great to just tell users to install both extensions and have it work without needing to disable the lsp from vscode-R. Does the current extension actually call the language server for any extra functionality outside of the usual LSP integration?
randy3k commentedon Sep 22, 2026
I agree, it was also the reason I separated r-syntax earlier.
grantmcdermott commentedon Sep 22, 2026
+1
Fred-Wu commentedon Sep 23, 2026
I support this. This would separate the functionality cleanly.
I’m not sure how widely R is used via VS Code in organisational environments. Recently, I’ve been trying to promote the support of using VS Code in one of our environments, as most people here use R and SQL Server or Snowflake. Requiring an additional extension would always raise questions or concerns initially.
randy3k commentedon Sep 23, 2026
I have unarchived REditorSupport/vscode-r-lsp.
[-]Proposal: separate language support from vscode-R again[/-][+]Separate language support from vscode-R again[/+]eitsupi commentedon Sep 26, 2026
Thank you everyone. I will try to find time to continue working on it.
As far as I can tell, no. The current LanguageService only uses the standard LSP client integration.
I couldn't find any custom requests or notifications to languageserver.
There is some custom lifecycle/process setup around it (R paths, renv, multi-server, TCP/stdio, etc.), but no extra protocol functionality.
vscode-R does separately provide session-aware hover and completions through sess, but those are registered directly as VS Code providers and do not go through the language server.