AshesITR
AshesITR
Rather minimal changes to the `.lintr` file would make it parseable R code, though. I'd be okay with allowing `.lintr` to also (in addition to being dcf-formatted) be parseable R...
Not a big fan of allowing two separate configuration files - what to do if both files exist in the same directory? `pkgdown`, `blogdown`, `covr` and GitHub Actions use YAML...
Hmm that seems hard because we intend on `linters` being configured via `linters_with_defaults()` or `linters_with_tags()`. For a transitional period, I'd be fine if `.lintr` would be parsed as YAML and,...
The only other advantage I can think of is `read.dcf()` is in base R.
Yeah, right. If we want to use R as the "format". I was comparing to YAML. We could do something like `evalq(source(".lintr", encoding = ??, local = TRUE), envir =...
True. But in `R` code it's more tempting to define other variables.
If we go with R, we should export a `lintr_config()` or `lintr_settings()` function that has all configuration options as arguments and does some validation.
Any other interesting and identifiable scopes? I had shiny modules in mind, but these, especially the UI part, are hardly discernable from functions. Maybe local / global (i.e. top-level or...
I've never used S4 myself. What would be a good way to detect S4 class assignments?
Seems like a separate feature, though some linters provide some (limited) support for S4, e.g., object_usage_linter scans S4 setMethod functions (assuming they are provided positionally) I think we can safely...