Assign default classes for code blocks of source, output, and so on

[atusy]

What about code blocks generated by chunks have one of the following classes chunk-source, chunk-output, chunk-message, chunk-warning, or chunk-error by default?

This enables easier and precise selections in CSS and JavaScript, which is friendly both for developers and users.

I already implemented it, but am having difficulty in passing tests (atusy@54db8c4).
So I want to ask if @yihui like my idea and if it is worth working on to pass tests.

Example applications

Cumbersome CSS selections in a PR rstudio/rmarkdown#1596 can be simplified (https://github.com/atusy/rmarkdown/blob/eb389d721b9f6cddd092234057c98150f70f898f/inst/rmd/h/default.html#L27-L42)

Selection of code blocks to fold by code_folding can be generalized.
Currently, folding is performed on code blocks with certain language classes, which may cause unexpected behavior (rstudio/rmarkdown#1603).
If folding is performed on code blocks with chunk-source, the unexpected behavior can be suppressed.
In addition, we don't have to update codefolding.js everytime we find additional language to be folded.

There's a request on folding results rstudio/rmarkdown#1453.
I am currently working on this issue, and seems to be easy.
However, a problem is that choice of folding button, which is currently code and hide.
For folding results, the choice is better to be output and hide.
I want to generate choices conditionally by detecting the code blocks have chunk-source class or chunk-output class.

xfun::session_info('knitr')

R version 3.6.1 (2019-07-05)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch), RStudio 1.2.1335

Locale:
  LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8    LC_MESSAGES=C             
  LC_PAPER=en_US.UTF-8       LC_NAME=C                  LC_ADDRESS=C               LC_TELEPHONE=C             LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

Package version:
  evaluate_0.14   glue_1.3.1      graphics_3.6.1  grDevices_3.6.1 highr_0.8       knitr_1.23.3    magrittr_1.5    markdown_1.0    methods_3.6.1   mime_0.7       
  stats_3.6.1     stringi_1.4.3   stringr_1.4.0   tools_3.6.1     utils_3.6.1     xfun_0.8        yaml_2.2.0 

---

By filing an issue to this repo, I promise that

• I have fully read the issue guide at https://yihui.name/issue/.
• I have provided the necessary information about my issue.
  • If I'm asking a question, I have already asked it on Stack Overflow or RStudio Community, waited for at least 24 hours, and included a link to my question there.
  • If I'm filing a bug report, I have included a minimal, self-contained, and reproducible example, and have also included xfun::session_info('knitr'). I have upgraded all my packages to their latest versions (e.g., R, RStudio, and R packages), and also tried the development version: remotes::install_github('yihui/knitr').
  • If I have posted the same issue elsewhere, I have also mentioned it in this issue.
• I have learned the Github Markdown syntax, and formatted my issue correctly.

I understand that my issue may be closed if I don't fulfill my promises.

[yihui]

Adding default classes to message, warning, and error messages sounds good to me. For source and output, I'm not quite sure, since it will certainly break some tests.

Before I submit the next version of knitr to CRAN, I'll have to check all reverse dependencies. At that time, I might discover packages broken due to this change. I just want to let you know in advance that there is a (small) chance that I'll have to revert this feature.

[atusy]

Thank you for the reply.

For source and output, I'm not quite sure, since it will certainly break some tests.

Yes, this is the point.
If the matter is only the tests, I'll try to update the tests too.

[yihui]

I don't mind updating tests in knitr, since this package is completely under my control. The problem is other people's packages and applications.

[atusy]

That's right. I'll check revdeps, but I'm not sure I can make it before releasing next knitr.

[yihui]

There is no urgency about this issue.

[atusy]

Alright 👍

[atusy]

Oh, I was forgetting about this PR for long time.

Now I feel this PR should go to rmarkdown package, i.e., add default classes with chunk hooks because of @yihui's comment on
rstudio/rmarkdown#1835 .
People may not like the knitr::knit to add classes to every code blocks regardless of output formats.

[yihui]

That sounds good to me.

[cderv]

@atusy should we close this in favor of a PR in rmarkdown ?

If so we could open an issue there, and reopen this one if we reconsider. What to you think ?

[atusy]

@cderv Thanks. I'll open the issue later.

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.