[renkun-ken]

New R files inherit VS Code's four-space indentation, which triggers lintr's default two-space indentation diagnostic. Set editor.tabSize to 2 in the existing [r] configuration defaults so editor indentation and languageserver formatting align with lintr's default.

Add a changelog note explaining that this language-specific default overrides general indentation settings and that users can select another width in [r] user or workspace settings. Automatic indentation detection still applies to existing files.

Fixes #1883.

Validation:

• Production build and VSIX packaging passed with pnpm exec vsce package --no-dependencies.
• Inspected the packaged manifest to confirm the R default is included.
• git diff --check passed.

[grantmcdermott]

Thanks!

[eitsupi]

I'm not convinced that overriding editor.tabSize is the right solution here.

In other languages, linting and editor formatting are generally kept separate.
For example,

• TypeScript uses ESLint separately
• Python has dedicated linting extensions such as Ruff
• rust-analyzer does not enable Clippy by default

These tools do not require the editor's indentation settings to match the linter's defaults.

More importantly, adding a language-specific editor.tabSize default overrides users' existing general editor.tabSize settings for R files, even if they explicitly chose a different indentation width.

I think the underlying issue is that languageserver enables lintr by default, including its opinionated style rules.
Rather than changing editor behavior to accommodate those rules, perhaps we should reconsider how linting is integrated into languageserver.

[renkun-ken]

Thanks, @eitsupi. After investigating how other language extensions and servers handle indentation, I agree with preserving users' existing editor preferences and reconsidering the default style-lint policy instead of merging this override as the fix for #1883.

I compared current upstream extension manifests and formatting implementations. The results are mixed, rather than a universal rule:

Language / tooling	Editor default	Formatter / server behavior
JavaScript / TypeScript, built-in	No language-specific tab-size override.	The client passes the editor's tabSize, indentSize, and space/tab preference to tsserver. Source
JavaScript / TypeScript, Prettier	No editor tab-size override.	Prettier's separate tabWidth defaults to 2, with project configuration taking precedence. This allows a two-space formatter default without changing the editor's four-space default. Default, integration
Python / Ruff	No tab-size override from the Python or Ruff extensions.	Ruff uses its own formatting configuration, defaulting to 4 spaces, rather than the formatting request's tab-size option. Configuration, handler
Rust / rust-analyzer	No tab-size override.	Delegates formatting to rustfmt and its configuration, rather than the request's tab-size option. Its check command defaults to check, not Clippy. Formatting, check default
Java / JDT LS	No tab-size override in the Red Hat extension.	Applies the client's tab size and space/tab preference to formatter options. Source
Go / vscode-go	Leaves tab width unchanged, but sets insertSpaces: false and enables formatting on save.	gopls uses Go's canonical formatting rules. Defaults, formatter
Ruby / Ruby LSP	Explicitly sets 2 spaces, using the same configurationDefaults mechanism as this PR.	Supports configured/detected formatters and integrated linting. Defaults
Dart / Dart Code	Explicitly sets 2 spaces, insertSpaces: true, and detectIndentation: false.	Uses the SDK formatter; its handler does not use the request's tab-size option. Defaults, handler

Ruby and Dart are direct precedents for the mechanism proposed here, so language-specific indentation defaults are an established approach. However, those precedents do not establish that we should change existing R editing behavior merely to accommodate lintr's default rules. Prettier is a useful counterexample: a two-space formatting default does not require overriding the editor's indentation setting.

The compatibility issue is decisive for me: under VS Code's settings precedence, this PR's language-specific default overrides even an explicitly configured general user or workspace editor.tabSize. Requiring users to restate their preference inside [r] is a behavior change, and documenting it does not remove that cost. My original description of this as a straightforward bug fix understated that tradeoff.

R languageserver already respects the client's formatting width, similarly to the built-in TypeScript integration and JDT LS. I would keep that behavior and leave the editor default unchanged here. For #1883, I favor a separate discussion about which opinionated style rules languageserver should enable by default, and whether those should be opt-in or independently configurable, while preserving useful correctness diagnostics and explicitly configured .lintr rules. That does not require removing lintr integration or disabling diagnostics wholesale.

Users who want two-space R editing can explicitly configure [r] with "editor.tabSize": 2; users who deliberately chose another width should retain that choice.