VS Code Extension not auto-closing quotes on ERB files

[TerrellAW]

Description

Ruby LSP Information

VS Code Version

1.100.1

Ruby LSP Extension Version

0.9.24

Ruby LSP Server Version

0.23.20

Ruby LSP Add-ons

• Ruby LSP Rails
• RuboCop

Ruby Version

3.4.3

Ruby Version Manager

mise

Installed Extensions

Click to expand

• csdevkit (1.19.63)
• csharp (2.76.27)
• ruby-lsp (0.9.24)
• rust-analyzer (0.3.2457)
• vscode-docker (1.29.6)
• vscode-dotnet-runtime (2.3.3)

Ruby LSP Settings

Click to expand

Workspace

{}

User

{
  "enabledFeatures": {
    "codeActions": true,
    "diagnostics": true,
    "documentHighlights": true,
    "documentLink": true,
    "documentSymbols": true,
    "foldingRanges": true,
    "formatting": true,
    "hover": true,
    "inlayHint": true,
    "onTypeFormatting": true,
    "selectionRanges": true,
    "semanticHighlighting": true,
    "completion": true,
    "codeLens": true,
    "definition": true,
    "workspaceSymbol": true,
    "signatureHelp": true,
    "typeHierarchy": true
  },
  "featuresConfiguration": {},
  "addonSettings": {},
  "rubyVersionManager": {
    "identifier": "auto"
  },
  "customRubyCommand": "",
  "formatter": "auto",
  "linters": null,
  "bundleGemfile": "",
  "testTimeout": 30,
  "branch": "",
  "pullDiagnosticsOn": "both",
  "useBundlerCompose": false,
  "bypassTypechecker": false,
  "rubyExecutablePath": "/home/mr-bones/.local/share/mise/installs/ruby/3.4.3/bin/ruby",
  "indexing": {},
  "erbSupport": true,
  "featureFlags": {},
  "sigOpacityLevel": "1"
}

Reproduction steps

1. Try using quotes in an html.erb file
2. Quotes don't auto close unless nothing else is on that line

[TerrellAW]

The problem seems to occur specifically within tags when defining things such as CSS class.

[vinistock]

Thanks for the report! This is likely some issue with our ERB language configuration for auto closing pairs.

[domingo2000]

This behaviour is related to Auto closing before configuration of the language. As vscode says "By default, VS Code only autocloses pairs if there is whitespace right after the cursor.".

Example:

<h1>|</h1>

Will not autoclose the configured auto closing pairs.

It is possible to add the character < to the list in autoCloseBefore. But this configuration applies to all the characters defined in autoclosing rules. So it generates a tradeoff:

• pros:
  • Help with autoclosing <% %> or <%= %> syntax common in erb.
• cons:
  • Gives strange behaviour when writing text like <h1>this shouldn't be autoclosed</h1>. Because when writing the ' character it is going to be autoclosed. So the writter should have to move left and errase one char.

I belive the cons are worse. So in my opinion if its really needed the user can set the configuration always for autoclosing in their own settings.json file like this.

"[erb]": {
        "editor.autoClosingQuotes": "always",
        "editor.autoClosingBrackets": "always", # This also if brackets are also wanted.
    }

On the other hand, when the cursor is in <%|%> tags the autoclose should be enabled, so we can add % to the autoclose before config 🤔.

¿Do you guys see any border case that could give wierd behaviour?

[vinistock]

Is it possible to configure the auto close to happen only inside ERB tags (<% %>)? If so, then I think it's fair to have it on inside, for Ruby code only and not the host language.

I agree that in other cases, the experience will likely be worse.

[TerrellAW]

The behaviour could be double-quote only, or have separate configuration for double and single quotes to avoid problems with apostrophes. Alternatively the auto-closing can occur only within a <tag> rather than between them. If this is not enough, the auto-closing can still require a white space after so long as it works in multi-line tags.

[domingo2000]

Is it possible to configure the auto close to happen only inside ERB tags (<% %>)? If so, then I think it's fair to have it on inside, for Ruby code only and not the host language.

I agree that in other cases, the experience will likely be worse.

I researched a little more here. The problem seems related to this issue in the VSCode implementation for embedded languages.

If we look at the grammar in erb.json we have not only the auto closing pairs for the ERB syntax, but also the grammar for ruby syntax. That is necessary right now because of the current bug. And if fixed should improve the auto closing in the ruby embedded language as defined here.

In the case that bug is resolved, the grammars in this repository should be updated for each to have the correct auto closing configuration for each language, the erb host, and the ruby embedded.

But the issue is from 2021 so probably is not going to be solved any soon.

[domingo2000]

Another thing to consider is that when working on embedded languages when the cursor is just before the closing tag, the language is still the host language.

Here are some exaples for ERB and for Markdown

Case 1: Case 2: Case 3: Similar in markdown

So even if the issue get's solved we are still in the erb context when typing "<%" because we land at case 2.

This could be improved by adding

  "autoClosingPairs": [
    ...
    ["<% ", " %>"],
    ...
   ]
  "autoCloseBefore": ";:.,=}])> \n\t%",

Based on the default autoCloseBefore we only add % to the autoCloseBefore to have better autoclosing moving from case 2 to case 1 with one space. Following erb lint recomendation and leaving vscode in the ruby context.

Here I have a demo that showcase that configuration:

Before:

https://github.com/user-attachments/assets/2ea02a65-0b8a-4ff0-aeca-b2c2adde5b55

After:

https://github.com/user-attachments/assets/15d25ba8-94ea-443c-a13d-909c7310f2a8

[vinistock]

I don't think the VS Code issue can be solved completely in a general way. The editor has no way of knowing, without language specific knowledge, about which parts of a file are the embedded vs host language. You need to know exactly the rules for embedding and that will depend on each templating language.

If there's a way to make it a bit smarter on our side, let's do it!

[github-actions[bot]]

This issue is being marked as stale because there was no activity in the last 2 months

[github-actions[bot]]

This issue is being marked as stale because there was no activity in the last 2 months

[github-actions[bot]]

This issue is being marked as stale because there was no activity in the last 2 months