-
-
Notifications
You must be signed in to change notification settings - Fork 872
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inline code chunks inheriting labels #1988
Comments
Thanks for the report! I think the original issue in magick is important here to understand. This happens because "knit_print.magick-image" <- function(x, ...){
if(!length(x))
return(invisible())
plot_counter <- utils::getFromNamespace('plot_counter', 'knitr')
in_base_dir <- utils::getFromNamespace('in_base_dir', 'knitr')
ext <- ifelse(all(tolower(image_info(x)$format) == "gif"), "gif", "png")
tmp <- knitr::fig_path(ext, number = plot_counter())
# save relative to 'base' directory, see discussion in #110
in_base_dir({
dir.create(dirname(tmp), showWarnings = FALSE, recursive = TRUE)
image_write(x, path = tmp, format = ext)
})
knitr::include_graphics(tmp)
} Currently this method, does not make any differences between inline and block chunk as it could (see inline argument for knit_print) I don't think we expect inline chunk to create figures as it is used to create plot files for plot evaluated by knitr. And you won't call So this is currently due to magick using an internal feature of knitr that does not work for inline chunk. However, I understand the need to have file created for inline insertion, specifically with svg. fontawesome does that, but it creates the filename itself without using knitr internal counter: So either magick could deal with inline figure differently, or create filemane differently. |
Thanks for the quick reply - my 2 cents (coming from someone who is not intimately familiar with the knitr internals) is that having fewer distinctions between inline and regular chunks will make things better for other developers integrating with knitr. For example, I realize that not all chunk options necessarily make sense but clearly the current "rule" that inline chunks don't have labels isn't true as I think the larger issue is that the current implementation of inline chunks is such that I as a developer don't have any mental model about where inline chunk settings will come from - global settings, inherited from previous chunk(s), some inline only defaults, etc. While I haven't tested or looked at the code for these other option and so I'm not sure about the details, I am worried that potentially non-obvious but related issues will happen down the road because of these inconsistencies between the way the chunks are treated. |
Thanks for your feedback. The mental model question is really interesting. As I understand, Inline R code and block chunk does not work the same currently. There is no options for inline R code and so no label. You cannot even change engine for inline code. It is only R code. So I guess my mental model for now is that any block chunk related functions won't work correctly in an inline R code. And I don't know if maybe documentation should be made more clear that inline R code are not chunks (with options and all), and functions for chunk would error on inline us. I believe your suggestion are related to the latter: Setting a specific I am thinking as I am writing and share it here for when I'll come back to this. |
It seems like a missed opportunity to not have them work in the same way - I'm not a regular python user but it would be somewhat frustrating to not be able to use python inline or have to do something convoluted through reticulate. Additionally, while having image output is probably the most compelling use case here I can also imagine edge cases like wanting to have an equivalent of Clearly these are mostly marginal use cases and would require a not insubstantial amount of work to implement but I think there is some value there. |
After working through the PR for magick ropensci/magick#313, I'm back to feeling like this is something that needs to be fixed on the knitr side of things. The primary cause of the issue here is the There are deeper issues here around the scope of Work arounds can be made in magick, rsicons, etc. but I think the ultimate fix is needed in knitr. |
That sounds reasonable to me.
I didn't read this thread very carefully, but I'll be happy to have this problem fixed in knitr. It will be great if someone could send a pull request, although I don't be able to review it by myself since I'll be on vacation starting tomorrow till mid-July. Perhaps @cderv can help review it (if it's not too complicated, you can merge it without my review). Thanks! |
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. |
It seems as though the label behavior for inline code chunks is inconsistent / problematic - specifically it seems that they inherit the label of the most recent proceeding code chunk, and in the case where an inline chunk occurs before any other it will have a blank label. See the sample Rmd below which demonstrates these behaviors:
I've come across a specific issue with this when using an inline code chunk to generate an image (via magick) as the
plot_counter()
is reset between the regular and inline chunk but since they share a label the plots from earlier regular chunk are overwritten.I would think that the more desireable behavior would be for the chunk label to increment regardless of the chunk type, the labels could continue to use
unnamed-chunk-*
or could have a specific inline chunk label variant e.g.inline-chunk-1
,inline-chunk-2
, etc.By filing an issue to this repo, I promise that
The text was updated successfully, but these errors were encountered: