Repository navigation
Conversation
An add-on can make the server handle a language besides Ruby and ERB. For example, my add-on, ruby-lsp-slim-lang, does this for the Ruby inside Slim templates. Since the extension only sends Ruby and ERB files to the server, an add-on like that can't be used from VS Code. This adds a `rubyLsp.addonLanguageIds` setting, empty by default. The extension adds each language ID listed there alongside Ruby and ERB in the client's document selector, in the language status items, and in the checks that activate a workspace when a document opens. It's opt-in, because without a matching add-on the server would parse those files as Ruby. Since any change under `rubyLsp` restarts the server, the client picks up the new list when it rebuilds its document selector. The language status items only read the list when the extension activates, however. A change only reaches them after a window reload, which I've left as is to keep this change small. For context, the add-on API has no way to register a document type, though @vinistock suggested in Shopify#1233 that one might be designed[1]. So, ruby-lsp-slim-lang currently patches the server's document store to create its own. That is separate from this change, which only concerns which files the extension sends. [1]: Shopify#1233 (comment) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Author
|
I have signed the CLA! |
bjeanes
added a commit
to bjeanes/ruby-lsp-slim-lang
that referenced
this pull request
Nov 11, 2026
The README said VS Code wasn't supported, because the Ruby LSP extension only sends Ruby and ERB files to the server. I've opened Shopify/ruby-lsp#4270 to add a `rubyLsp.addonLanguageIds` setting that sends other languages too. Until a release of the extension includes it, the README explains how to build the extension from my fork and which settings to use. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Related to #1233.
An add-on can make the server handle a language besides Ruby and ERB. For example, my prototype add-on, ruby-lsp-slim-lang, does this for the Ruby inside Slim templates. That follows @vinistock wondering in #1233 whether templating engines may be a better fit for add-ons2.
However, the extension only sends Ruby and ERB files to the server. As such, an add-on like that can't be used from VS Code. In Neovim, where the client's
ruby_lspconfig decides which file types to send, addingslimto it is enough for the add-on to work.Implementation
This adds a
rubyLsp.addonLanguageIdssetting, empty by default. The extension adds each language ID listed there alongside Ruby and ERB in:It's opt-in, because without a matching add-on the server would parse those files as Ruby.
Since any change under
rubyLsprestarts the server, the client picks up the new list when it rebuilds its document selector. However, the language status items only read the list when the extension activates. They won't show a change to the setting until the window is reloaded, which I've left as is to keep this change small.The extension's ERB delegation middleware checks for
erbexplicitly. Requests for other languages therefore go straight to the server.Note
The add-on API has no way to register a document type, though @vinistock suggested in #1233 that one might be designed. So, ruby-lsp-slim-lang currently patches the server's document store to create its own. That is separate from this change, which only concerns which files the extension sends.
I made this change with Claude Code, which is why the commit has a
Co-Authored-Bytrailer. I've reviewed it and tested it in VS Code myself, and I'm happy to drop the trailer if you'd prefer.Automated Tests
I added unit tests for the list of supported language IDs, both by default and with the setting.
Manual Tests
gem "ruby-lsp-slim-lang", require: false, github: "bjeanes/ruby-lsp-slim-lang"to theGemfileand runbundle install..slimfiles get theslimlanguage ID."rubyLsp.addonLanguageIds": ["slim"]to the workspace settings, then reload the window..slimtemplate and go to the definition of a helper or constant it uses. It should jump to the Ruby definition.