lintr::lint(text=) no longer reads personal settings

[bastistician]

(This doesn't affect a release yet, but is an issue of the recently merged #2805, raised here per request of @MichaelChirico.)

The recent change from #2805 means that ~/.lintr settings are no longer read when linting text input (inline_data), e.g., lintr::lint(<R-code-as-string>), which is what Emacs-ESS uses to lint code in R buffers. So with the current development version of lintr I'd only see notes from the default_linters.

Here is an example where the non-default duplicate_argument_linter() is added in the settings:

library("lintr")
cat("linters: linters_with_defaults(duplicate_argument_linter())\n", file = tf <- tempfile())
options("lintr.linter_file" = tf)
lint(text = "list(x = 1, x = 2)")  # parse_settings is TRUE by default
## i No lints found.

In lintr 3.2.0, this did produce a "lint".

[MichaelChirico]

Thanks for the report. I think in my head I did this intentionally with the thought "of course you shouldn't expect settings to be picked up if you're using text=", so of course this goes and proves me wrong :)

I'm not very familiar with Emacs/ESS backend, and a quick Google was no help -- why isn't Emacs just doing lint(<file>) instead of lint(text=)?

[MichaelChirico]

I see here it's Flymake doing the linting:

https://github.com/emacs-ess/ESS/blob/0eb240bcb6d0e933615f6cfaa9761b629ddbabdd/lisp/ess-r-flymake.el

But I can't find Flymake's own code.

[bastistician]

why isn't Emacs just doing lint(<file>) instead of lint(text=)?

Buffers aren't necessarily visiting files. For those that do, linting should use the (edited) buffer content not what has been written (back) to the file. I'm no Emacs expert either but I guess that must be the reason.