Old to R new to VSCode - lintr is annoying

[irishmhw]

Good afternoon,

I have been using R for a while, and have moved to using VSCode to streamline the use of Python and Julia too. I understand the purpose of linting and lintr. However, when I am just trying to make something work, it is distracting and I can't focus with all of those squiggly lines.

I have seen recommendations for going to the extension settings or typing in a line to make using lintr false. I don't know where those options even are and some of them I can't get to work. Is there a way of just turning off or uninstalling linting in general, I can run those later if I really want to.

Thank you,

[renkun-ken]

Looks like we might need a dedicated section on customizing linting settings in project wiki

As for now, you could disable linting completely by setting "r.lsp.diagnostics": false in vscode settings.

However, you won't see syntax errors when the code simply cannot be parsed. I assume you need at least see syntax errors. So you might need a customized global .lintr config file via executing file.edit("~/.lintr") in R or simply create and edit ~/.lintr with the following content:

linters: list()

Then lintr will by default only show parse errors and no other linters will be used in linting.

You could add some linters to the config file according to https://lintr.r-lib.org/articles/lintr.html#configuring-linters.

[renkun-ken]

A new wiki page https://github.com/REditorSupport/vscode-R/wiki/Code-linting is added.

[Jacinto27]

I think we should revaluate this approach. I've been scouring as many issues as I can regarding this (even opening ones of my own) and generally I've seen the following:

• People having issues on the languageserver repo because they were fidgeting with the lintr files, some of them on vs code. The issue isn't with the lintr itself, but I think the reason they were fidgeting with these files in the first place can be traced back to this issue.

• Issues on this repo regarding the excessive linting options (two to be exact) besides these comments in the debate section.

I think suggesting end users who -from what I've seen- are mostly PhDs, economists, etc, with editing their own extension installation makes it a prone environment for the first type of issue (bricking your installation by accident), or would incentivize them to jump to a plug-and-play solution like R-studio.

When I opened an issue on the lintr package regarding this, they mentioned that this vs code extension ships somewhat customized defaults,( perhaps due to compatibility issues ) so it would not be a stretch to ship defaults with many of these "overbearing linting comments" turned off, and add in the wiki a section to inform the user which linting and styling is off, how to turn it back on, and also how to further customize the linting options (just like it currently is on the wiki).

I think the configuration posted by @albert-ying here #1400 (comment)_ is a good starting point.

[Jacinto27]

Most users will probably not want to disable a linting package entirely, static error checking is usually a boon, and generally the lintr package is quite good, but they WILL try to edit it so that it is less overbearing ( as seen by the comments and issues opened regarding this on this same repo).

Having the option of: edit your own installation or turn it off entirely is not viable when:

1. Your users are most likely not coming from a programming background, and simply need a programming solution (medical PhD researcher looking for a stats analysis tool that's free, for example)

2. Editing the installation can lead to conflicts with the other required packages such as languageserver (probably resolved by now since the issues are mostly a year old, but doesn't mean they won't happen again)

Even if the vscode extension does not "ship" anything, (because they use the "default") the file that you need to edit to turn off the specific linting options can be easily found inside the repo (as noted by Michael) and is indeed the file you must edit to successfully turn the comments off (as noted in the documentation). So editing this file's defaults (and adding the documentation changes) is something the repo can do to solve the issue from the get go instead of relying on the end user.

As a side note, I've not seen people comment on the "annoying linting messages" while using other IDEs like Pycharm, I haven't tried them myself, but maybe they have a way of handling them in a way that isn't as "on your face" as vs code is ? What I do know is that I haven't had as many comments on my code when using other languages and their linters in vs code.

[eitsupi]

So editing this file's defaults (and adding the documentation changes) is something the repo can do to solve the issue from the get go instead of relying on the end user.

What do you mean by "ship"?
Do you want lintr to just stop throwing errors in vscode, and then users will be confused that the results are different on command line than they are in vscode?

[Jacinto27]

By "ship" I mean deliver to the end user, having the vs code extension deliver less overbearing code flags to the end user by default would be better than leaving it up to the end user to fix such issue. And to do this despite the fact that what the extensions delivers is the default behaviour of the lintr package.

The problems I'm discussing are not whether or not vscode should throw errors , I'm
discussing the blue flag errors ( and other styling or frequently appearing minor errors) that the lintr package throws that are annoying and overbearing. You can check which ones in particular by looking at linters that Albert edited /turned off, or the ones turned off on the original issue here #1400 (comment)

[MichaelChirico]

One clarification -- I am not sure vsCode ships any custom .lintr config. I only saw this comment #1400 (comment) which suggested that's the case because of a different line length default.

[Jacinto27]

I think that file is created with the vscode-R extension installation, I don't think base VS code has anything pre-installed for the R language.

EDIT 1

I just checked, it's not, only the only lintr file is inside the redist extension, which does not affect the default behavior of lintr, this is what @eitsupi mentioned in the original issue.

EDIT 2

I checked the repo and it indeed looks like the vscode-R package uses the default lintr settings just like eitsupi said, the create .lintr command does not create anything by default, and the vanilla extension simply goes without a .lintr file which means it reads directly the defaults set up in the lintr package.

[Jacinto27]

I've researched how other language extensions handle linting and found the following:

• Some extensions have separate linting extensions, while others integrate linting, like R with lintr.
• Integrated linters can typically be customized via settings.json, but lintr uses a .lintr file, the global configuration is read from the home directory (I don't think this can be changed).
• Just like @eitsupi said the R extension doesn't ship a .lintr file in the user's home directory, and the default lintr behaviour is to fall back to it's default configuration.
  • This is actually a good practice, editing the user's home directory usually goes beyond the scope of a vs code extension.
• Workspace settings are supported, which is the best configuration option within VS Code's limitations.

Given this I think the best that could be done to tackle this issue is:

• In the main read-me page (where it suggests radian and languageserver) add a step on configuring the .lintr file, linking the documentation created at the beggining of this debate section.
• (Optionally) Provide a suggested linting configuration to help users avoid disabling linting entirely. Could be one made especifically for vs code, or made by pooling ideas from other users.

Since these are simple documentation changes I'm willing to PR them, but since it's also a design choice/image choice I'd work with approval from @eitsupi who has worked on most of the linting integration.