Pkgdown: Chunk code is not highlighted when comment = NA

[Eluvias]

Changing the default value of the comment setting will remove chunk's highlighting.

reprex

temp <- tempfile()
usethis::create_package(temp, rstudio = FALSE, open = FALSE)
usethis::proj_activate(temp)

```r
usethis::use_article("test")

````
writeLines("---
title: test
output:
  rmarkdown::html_vignette:
vignette: >
 %\\VignetteIndexEntry{test}
 %\\VignetteEngine{knitr::rmarkdown}
 %\\VignetteEncoding{UTF-8}
---
 ```{r setup}

knitr::opts_chunk$set(
  collapse = TRUE,
  cache = FALSE,
  comment = NA
)
 ```
```{r OK}

x <- data.frame(a = 1:4, b = 5:8)

y <- list(NULL)

```{r NOTOK}

x <- data.frame(a = 1:4, b = 5:8)

y <- list(NULL)

x

 ", 
con = "vignettes/test.Rmd")
````
```r
pkgdown::build_site()

outputs

comment = "#" works:

[jayhesselberth]

This is expected behavior, page highlighting relies on a leading # to identify comments.

[Eluvias]

@jayhesselberth it's not about comments in general, but commenting out the code output; knitr's chunk setting comment was respected before.

For example now it will break the highlighting if you opt not to comment out the output, i.e., comment = NA.

[jayhesselberth]

knitr's comment is being respected by pkgdown, that's why your output changes.

comment = NA just tells knitr not to use a comment character (your first output above).

[Eluvias]

This is what I was getting up to v1.4.1.

[Eluvias]

And if it is rendered with knitr:

[Eluvias]

@jayhesselberth here are the differences:

v1.5.1

v1.4.1

knitr

[jayhesselberth]

Sorry, I see the issue now, I was focused on the comments themselves.

[jayhesselberth]

Might be related to changes in f49ffa50fb609b72e7fd09a334bbbc707404e7aa

[wkmor1]

Here is another minimal example:
r package.skeleton("x") dir.create("x/vignettes") cat("```r\n#\n```", file = "x/vignettes/x.Rmd") pkgdown::build_article("x", "x") html <- xml2::read_html("x/docs/articles/x.html") src <- xml2::xml_find_first(html, ".//div[contains(@class, 'sourceCode')]") as.character(src)
under 1.4.1 this would return
r [1] "<div class=\"sourceCode\" id=\"cb1\"><pre class=\"sourceCode r\"><code class=\"sourceCode r\"><a class=\"sourceLine\" id=\"cb1-1\" data-line-number=\"1\"><span class=\"co\">#</span></a></code></pre></div>"
whereas as of https://github.com/r-lib/pkgdown/commit/f49ffa50fb609b72e7fd09a334bbbc707404e7aa it returns
r [1] "<div class=\"sourceCode\" id=\"cb1\"><pre class=\"r\">#</pre></div>"
This function https://github.com/r-lib/pkgdown/blob/aea6864792d681f64a9e1b8c52fe24668b2e4f55/R/highlight.r#L4-L28 is stripping the markup that the syntax highlighting css would target when parsing the R code produces an empty expression.

Note that the behaviour is not just triggered if the comments are changed with opt_chunks$set but will happen to any code block that consists of comments only (such as in the reprex above) for example for all output code chunks when collapse = FALSE

[jayhesselberth]

Highlighting of empty expressions is fixed.

I don't think we should encourage use of comment = NA or collapse = TRUE as it leads to a syntax error when copy / pasted.

[Eluvias]

I still see the problem.
Can you please confirm that is fixed by running the reprex at the very top?

pkgdown 1.5.1.9000 2020-04-23 [1] Github (r-lib/pkgdown@3b43ddb)

[wkmor1]

@Eluvias Unfortunately https://github.com/r-lib/pkgdown/pull/1307 wasn't really supposed to fix these cases. Only cases that produced empty expressions (e.g., comments only) rather than syntax errors. In any case it looks like https://github.com/r-lib/pkgdown/pull/1307 is causing problems elsewhere so wont be making it in at this stage anyway.

[hadley]

This is technically a change in behaviour, but I don't think it's a bug. We now use R itself to do the syntax highlighting, so we can only syntax highlight valid R code.

[wkmor1]

@hadley, Agreed. But code that is just # commented lines is valid (right?) and this change has stopped highlighting such comment only blocks. I feel like I might have muddied the waters a bit conflating what are possibly two separate issues, albeit arising from the same change. I can open an new issue if needed or just leave you with #1310 to decide?

[hadley]

@wkmor1 I'd recommend opening a new issue with a minimal reprex