vscode-R icon indicating copy to clipboard operation
vscode-R copied to clipboard

.lintr file is ignored by VSCode extension

Open SamDM opened this issue 2 months ago • 3 comments

Describe the bug

I have a ${workspaceFolder}/.lintr file as described here: https://github.com/REditorSupport/vscode-R/wiki/Code-linting , yet the settings in the .lintr file do not affect diagnostics in VSCode. I.e. I still see squiggly underlines for lints that I have disabled.

Running lintr::lint_dir() produces no lints as expected.

I am running VSCode in a devcontainer, so perhaps it has something to do with that. Except for my .lintr file being ignored, everything else of the R extension seems to work fine.

To Reproduce Steps to reproduce the behavior:

  1. Start a devcontainer with R installed in it. Mine is:

Dockefile:

FROM debian:12

# Set a non-interactive mode for apt and install necessary tools
ENV TZ=UTC
ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update && apt-get install -y --no-install-recommends \
      # needed for later
      build-essential \
      ca-certificates \
      curl \
      dirmngr \
      gnupg \
      locales \
      lsb-release \
      openssh-client \
      software-properties-common \
      sudo \
      wget \
      xz-utils \
    && sed -i '/en_US.UTF-8/s/^# //g' /etc/locale.gen \
    && locale-gen \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

ENV LANG=en_US.UTF-8
ENV LC_ALL=en_US.UTF-8

# Some install scripts assume bash, this makes following RUN commands use `bash` instead of `sh`.
# The `-c` flag says: "accept a command instead of starting interactive mode".
SHELL ["/bin/bash", "-c"]

RUN wget -qO- https://cloud.r-project.org/bin/linux/debian/marutter_pubkey.asc | tee /etc/apt/trusted.gpg.d/cran_debian_key.asc \
    && add-apt-repository "deb https://cloud.r-project.org/bin/linux/debian $(lsb_release -cs)-cran40/" \
    && apt-get update && apt-get install -y --no-install-recommends \
      r-base \
      libcurl4-openssl-dev \
      libfontconfig1-dev \
      libfreetype6-dev \
      libfribidi-dev \
      libharfbuzz-dev \
      libjpeg-dev \
      libpng-dev \
      libssh-dev \
      libssl-dev \
      libtiff5-dev \
      libxml2-dev \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# R packages: VSCode integration
# See https://github.com/REditorSupport/vscode-R/issues/1588 for httpgd repo
RUN R -e "install.packages(c('languageserver', 'httpgd'), Ncpus=parallel::detectCores())" \
    && R -e "install.packages('httpgd', repos = c('https://community.r-multiverse.org', 'https://cloud.r-project.org'), Ncpus=parallel::detectCores())"

devcontainer.json:

{
  "name": "singleplant-var-bethedge",
  "build": {
    "dockerfile": "Dockerfile"
  },
  "mounts": [
    "source=${localEnv:HOME},target=${localEnv:HOME},type=bind,consistency=cached,readonly",
    "source=${localEnv:SSH_AUTH_SOCK},target=/ssh-agent,type=bind"
  ],
  "remoteEnv": {
    "GIT_CONFIG_GLOBAL": "${localEnv:HOME}/.gitconfig",
    "SSH_AUTH_SOCK": "/ssh-agent"
  },
  "runArgs": [
    "--network=host"
  ],
  "customizations": {
    "vscode": {
      "extensions": [
        "reditorsupport.r",
        "rdebugger.r-debugger",
        "mechatroner.rainbow-csv"
      ]
    }
  }
}
  1. Create a .lintr file .lintr
linters: linters_with_defaults(
    line_length_linter(100)
  )

  1. Create an R file violating a default linting rule:

foo.R

long_line <- "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo"

  1. Observe the max 80 characters line lint being triggered, while it shouldn't.

Squiggly line under first line of code in foo.R, and diagnostics panel says:

[{
	"resource": "/workspaces/singleplant-var-bethedge/foo.R",
	"owner": "_generated_diagnostic_collection_name_#0",
	"code": {
		"value": "line_length_linter",
		"target": {
			"$mid": 1,
			"path": "/reference/line_length_linter.html",
			"scheme": "https",
			"authority": "lintr.r-lib.org"
		}
	},
	"severity": 2,
	"message": "Lines should not be more than 80 characters. This line is 100 characters.",
	"source": "lintr",
	"startLineNumber": 1,
	"startColumn": 1,
	"endLineNumber": 1,
	"endColumn": 101,
	"origin": "extHost2"
}]

Can you fix this issue by yourself? (We appreciate the help)

No, no but I'll happily dig deeper if someone can point me in the right direction.

Please attach setting.json ${workspaceFolder}/.vscode/settings.json

{
  "editor.rulers": [
    100
  ],
  "r.lsp.debug": true
}

By inheriting from user/remote/workspace settings, the following settings apply:

// R.exe path for windows
"r.rterm.windows": "",

// R path for Mac OS X
"r.rterm.mac": "",

// R path for Linux
"r.rterm.linux": "",

// R command line options (i.e: --vanilla)
"r.rterm.option": [
  "--no-save",
  "--no-restore"
]

// An optional encoding to pass to R when executing the file, i.e. 'source(FILE, encoding=ENCODING)'
"r.source.encoding": "UTF-8",

// Keeping focus when running
"r.source.focus": "editor",

// Use active terminal for all commands, rather than creating a new R terminal
"r.alwaysUseActiveTerminal": false,

// Use bracketed paste mode
"r.bracketedPaste": false,

// Enable R session watcher
"r.sessionWatcher": true,

// Delay in milliseconds before sending each line to rterm (only applies if r.bracketedPaste is false)
"r.rtermSendDelay": 8,

Expected behavior

My .lintr file is being parsed by the VSCode extension (i.e. provided to the underlying language server) and hence the long line lint is not being shown.

Environment (please complete the following information):

  • OS: Ubuntu 24.04.3 LTS (host) and Debian GNU/Linux 12 (bookworm) (container)
  • VSCode Version:
Version: 1.106.3
Commit: bf9252a2fb45be6893dd8870c0bf37e2e1766d61
Date: 2025-11-25T22:28:18.024Z
Electron: 37.7.0
ElectronBuildId: 12781156
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Linux x64 6.14.0-36-generic
  • R Version: R version 4.2.2 Patched (2022-11-10 r83330) -- "Innocent and Trusting"
  • vscode-R version: 2.8.6

Additional context

In the terminal the .lintr file is applied correctly:

root@ledono25:/workspaces/singleplant-var-bethedge# R -e "packageVersion('lintr'); lintr::lint_dir()"

R version 4.2.2 Patched (2022-11-10 r83330) -- "Innocent and Trusting"
Copyright (C) 2022 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> packageVersion('lintr'); lintr::lint_dir()
[1] ‘3.3.0.1’
ℹ No lints found.
> 
> 
root@ledono25:/workspaces/singleplant-var-bethedge# cat ./foo.R
long_line <- "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo"

root@ledono25:/workspaces/singleplant-var-bethedge# cat ./.lintr
linters: linters_with_defaults(
    line_length_linter(100)
  )

root@ledono25:/workspaces/singleplant-var-bethedge# 

SamDM avatar Dec 10 '25 10:12 SamDM

R_lsp_output.log

SamDM avatar Dec 10 '25 10:12 SamDM

I am also getting the same issue, while trying to setup R in VS Code today.

Running lintr::lint_dir() correctly recognises my .lintr file inside my project folder, but in VSCode I still see warnings about linters I've turned off.

My Setup:

  • MacOS Tahoe
  • VS Code 1.106.3 (Universal)
  • This Plugin (latest version - 2.8.6)

For testing, I temporarily disabled all other plugins.

My .lintr file:

linters: linters_with_defaults(line_length_linter = NULL)

My test.R file:

long_line <- "This is a very long line that exceeds the default line length limit set by lintr package in R which is usually 80 characters."

Output of running lintr::lint(filename="test.R"):

ℹ No lints found.

What I see in VS Code:

Image

dave-mills avatar Dec 10 '25 18:12 dave-mills

I'm also getting this issue.

Is there any workaround?

javieriserte-at-calice avatar Dec 11 '25 16:12 javieriserte-at-calice