Unnamed chunk numbering inconsistency (RStudio vs Knitr)

[zeehio]

Thank you for your work on your packages. I am reporting here a mildly annoying issue:

Unnamed chunks receive different numbers depending on whether RStudio browsing menu is used or knitr is knitting. This inconsistency is mildly annoying, because it makes it a bit difficult to figure out where is knitr knitting.

(Full Rmd available in this gist: https://gist.github.com/zeehio/9b631e5b25ff9b1ddeeed2ffe2b64436)

In this image, the first and second chunks are named. The third one is unnamed. RStudio labels the third chunk in the dropdown menu as "Chunk3", while knitr::knit() labels it as unnamed-chunk-1.

On larger Rmd documents with some named and some unnamed chunks, when knitr gets stuck on a chunk that is unexpectedly slow, I often try to figure out what chunk it is to address the performance bottleneck.

I think the RStudio numbering makes more sense to me, so I am filling the bug here. However, an alternative would be to patch RStudio so unnamed chunks appear as "Chunk 3: unnamed-chunk-1" so I can tell where to go.

Not a pressing issue, but if it is a low hanging fruit I'd love to see it fixed.

Session info:

R version 4.2.2 Patched (2022-11-10 r83330)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 22.04.1 LTS

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

Package version:
evaluate_0.20 graphics_4.2.2 grDevices_4.2.2 highr_0.10
knitr_1.42 methods_4.2.2 stats_4.2.2 tools_4.2.2
utils_4.2.2 xfun_0.37 yaml_2.3.7

Thanks for your time reading this issue and thank you for considering addressing this.

---

By filing an issue to this repo, I promise that

• I have fully read the issue guide at https://yihui.org/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.

[cderv]

Currently unamed chunk in knitr are counted among unnamed chunk, and it does not take into account named chunk

knitr/R/parser.R

Lines 168 to 171 in 78f1db5

	unnamed_chunk = function(prefix = NULL, i = chunk_counter()) {
	if (is.null(prefix)) prefix = opts_knit$get('unnamed.chunk.label')
	paste(prefix, i, sep = '-')
	}

@yihui I wonder if counting considering all chunks could break something. Unnamed chunk number are quite internal...
However it would break all the cache and other resource file where chunk name is used right ?

@zeehio Naming all the chunk is still the best way to track chunks explicitly. Unnamed chunk are named internally because a name is required for some features. So this is somehow related to #2228 where a function could explicitly name all the unnamed chunks.

[yihui]

Not a pressing issue, but if it is a low hanging fruit I'd love to see it fixed.

It is a low hanging fruit if a document doesn't contain child documents. When child documents are involved, I'm not sure how to number unnamed chunks. One idea is to append numbers to the label of the current chunk that contains child documents, e.g., unnamed-chunk-3-1 indicates an unnamed chunk that is the first chunk in child document, and the child document is imported by the third chunk in a parent document. However, this method has a danger of clashing with existing chunk labels. For example, if a chunk foo imports a child document, the first unnamed chunk in the child document will be assigned a label foo-1, but the label foo-1 may already exist.

I think one way to improve the progress reporting is to add the line numbers after the chunk label. That info should make the progress much clearer.

However it would break all the cache and other resource file where chunk name is used right ?

Yes.

[zeehio]

Thanks for your replies. I've made a minimal pull request on #2250 to include the line number (and the file name, since we have child documents) into the progress bar.

If this idea is not convincing to you I have no issues in closing the pull request or changing it at your convenience.

Thanks for your time :-)

[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.