Using a nolint= chunk option for Rmd

[MichaelChirico]

Currently, if we want to skip linting certain lines in an Rmd file, we have two options (IIUC):

1. Include # nolint or # nolint start / # nolint end in the code just like for .R scripts. This is somewhat awkward for .Rmd because .Rmd are especially made for reading, and readers are likely to be confused by these tags that have nothing to do with the tutorial (e.g.) per se.

2. Include invisible chunks starting/stopping nolint ranges "behind the scenes", e.g.

   ```{r nolint_start, echo = FALSE}
   # nolint start: assignment_linter.
   ```
   
   ```{r regular_chunk, ...}
   x = 4
   ```
   
   ```{r nolint_stop, echo = FALSE}
   # nolint end: assignment_linter.
   ```
   

This is also far from ideal and pretty limiting. It's OK for hiding whole files, but impractical for excluding small portions of code, as well as hugely increasing the amount of clutter in the source.

A good workaround IMO would be for lintr to understand an Rmd chunk option, e.g. nolint = :

```{r regular_chunk, ..., nolint = TRUE}
x = 4
```

I propose the following API for this option:

• nolint = TRUE: exclude the chunk from linting
• nolint = integer(n): exclude the lines listed in nolint, given relative to the chunk (similar to eval, but we use lines instead of expressions)
• nolint = list(linter1 = TRUE || integer(n1), ..., linterk = TRUE || integer(nk)): linter-specific exclusions are given via named elements of a list, with the list elements' values being used just like one of the first two options

This should be a no-op from knitr's perspective and still analyzed statically, so e.g. knitr::opts_chunk is not a valid way to set this "pseudo-chunk option".

[MichaelChirico]

Small addendum: I think for the case of globally shutting off lintr for a file (when a .lintr file is unavailable), the invisible chunks option mentioned in 2. above is an OK solution. Especially since most people already have a setup, eval=FALSE chunk at the top of their Rmd to begin with that can be used for the # nolint start portion.

[jennybc]

I have just developed a need for this. In usethis, I recently switched from masking some undesirable functions (one of which is interactive()) to linting for them. This is an internal matter, i.e. I want to use rlang::is_interactive() inside usethis, but I'm not asserting that it's always superior. And, in fact, I have an eval = FALSE code chunk in a vignette that shows the (legitimate) use of interactive(). I would definitely use a nolint = TRUE chunk option in this case, if it existed.

[MichaelChirico]

related to this, I've been thinking lately we might want to update the Lint data structure for Rmd (and later, ipynb) to include a cell_number field (and line_number_in_cell).

it might be good to add that before 3.0 release, WDYT @AshesITR ?

[jennybc]

BTW I have found one more way to do this currently, that works well for my very small example. Remember, I've got interactive() in my undesirable function linter.

```{r, eval = FALSE, echo = 2:4}
# nolint start
if (interactive()) {
  suppressMessages(require(devtools))
}
# nolint end
```

[MichaelChirico]

snazzy!! indeed the cleanest workaround I've seen. it still seems like a lot of over head relative to what could be...

[AshesITR]

related to this, I've been thinking lately we might want to update the Lint data structure for Rmd (and later, ipynb) to include a cell_number field (and line_number_in_cell).

it might be good to add that before 3.0 release, WDYT @AshesITR ?

The idea sounds interesting. What would this alternative location information be used by?
Also, we should think about what chunks would be counted (other languages? Plain highlighting chunks? Verbatim chunks?

Related idea: We could also try to lint inline R code

Text text `r inline_r_code` text

[MichaelChirico]

e.g. it would be useful for #741.

it could also be useful for ipynb, where the concept of line_number is a bit muddled -- since the file is stored as .json which most users never see, but global line numbers may not be displayed by default either (IIRC jupyter needs a widget to show line #s), reporting lints as (Cell x, line y) may be better.

re: inline code -- have thought of this, and it could be a useful option (esp if using any nontrivial expression), but I'm not sure what to do with line numbers.

knitr evaluates such expressions in order with the file right (i.e. directly after the preceding chunk)? does knitr::purl extract these?

[MichaelChirico]

@jennybc btw, if you'd rather just turn off certain linters for vignettes, you can do that in the config file, example:

https://github.com/Rdatatable/data.table/blob/036fb48f6d7b039e485b1a39d47204fddcfc6a87/.ci/.lintr.R#L87-L92

#2172 and #1976 are other FRs to improve ergonomics around this approach.