lintr ≥ 3.3: .lintr settings ignored in VS Code live linting due to missing parse_settings = TRUE

### Summary With lintr ≥ 3.3.x, `.lintr` settings (e.g. custom line length limits) are no longer respected during live linting in VS Code, even though the same setup worked previously with identical versions of the VS Code R extension and languageserver. The root cause appears to be a documented breaking change in lintr 3.3.0-1: settings are no longer applied automatically when linting in-memory text buffers unless `parse_settings = TRUE` is explicitly passed to `lintr::lint()`. VS Code live linting appears to lint editor buffers via `lint(text = ...)` without this flag, causing lintr defaults (e.g. 80-character line length) to be used instead of `.lintr`. --- ### Environment - OS: Windows 11 Enterprise - R: 4.5.2 - lintr: 3.3.3.0 - languageserver: 0.3.16 - VS Code R extension: 2.8.6 - VS Code: current stable Note: the same versions of the VS Code R extension and languageserver were used for months before an OS reinstall, during which `.lintr` *was* respected. The effective change was upgrading lintr from ~3.2.x to ≥3.3.x. --- ### Reproducible example #### 1. `.lintr` file ``` linters: lintr::linters_with_defaults( line_length_linter = lintr::line_length_linter(100) ) ``` #### 2. File-based linting (works) Create a file test.R with a single line between 80 and 100 characters. `lintr::lint("test.R")` Result: no line-length warning, as expected. #### 3. Text-based linting (defaults used) ``` lintr::lint( text = "a <- \"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"" ) ``` Result: line-length warning at 80 characters. #### 4. VS Code behavior Opening the same file in VS Code produces a line-length warning at 80 characters, matching the behavior of lintr::lint(text = ...), not lintr::lint(filename). Project-local .lintr and global ~/.lintr are both ignored. ### Relevant lintr changelog entry From lintr 3.3.0-1: lint() no longer picks up settings automatically in ad hoc invocations like lint("text\n") or lint(text = "str"). You should set parse_settings = TRUE to force settings to be read. https://lintr.r-lib.org/news/index.html#deprecations--breaking-changes-3-3-0-1 This explains the observed behavior, but the changelog does not mention editor or language-server integrations explicitly. ### Expected behavior VS Code live linting should respect .lintr settings in the same way as file-based linting, as it did with lintr ≤ 3.2.x. ### Suggested fix / direction When invoking lintr on in-memory editor buffers, the integration should: pass parse_settings = TRUE to lintr::lint(), or lint files on disk when possible instead of raw text buffers At present there is no user-side configuration that can enable this.