r in-line expression evaluated even in quoted context with double backtick

[kortschak]

System details

RStudio Edition : Desktop
RStudio Version : 1.2.1335
OS Version      : linux (ubuntu)
R Version       : 3.6.1

Steps to reproduce the problem

knit the following Rmd

---
title: "backticks inside your backticks..."
output: html_document
---

This shows that the in-line code mark is evaluated at a higher preference than the wrapping backticks:
this `` `r nrow(c())` `` should be rendered as `<code>` looking something like this `` ` r nrow(c())` ``
(without the space needed to break the `` `r`` token).

Describe the problem in detail

The internal `r expression` is evaluated before the enclosing double backticks. This makes it impossible to express an inline R expression as quoted code (the whole point of the double backticks in Markdown).

Describe the behavior you expected

I expect that the enclosing double backticks should take priority over the in-line expression evaluation. This is the more likely intention behind writing this sequence of bytes in a file and there is no other way to obtain knitted output. If a user did want generated <code>-wrapped in-line expressions, this can be obtained exactly that way, by <code>`r expression`</code>.

[ronblum]

@kortschak Thank you for reporting the issue. I can reproduce this in RStudio Desktop 1.2.5001 on MacOS Catalina 10.15. This might be an issue with R Markdown, not RStudio, but I'll mark it as a bug for now.

Reference: https://bookdown.org/yihui/rmarkdown/markdown-syntax.html#inline-formatting

[kevinushey]

I'm fairly sure this is an issue with rmarkdown -- you can reproduce the issue independent of RStudio. For example, with the document:

---
title: "backticks inside your backticks..."
output:
  html_document:
    keep_md: true
---

Don't render me: `` `r 123456` ``

I see the following after render:

$ cat test.md
---
title: "backticks inside your backticks..."
output:
  html_document:
    keep_md: true
---

Don't render me: `` 1.23456\times 10^{5} ``

No idea where the \times 10^{5} is coming from, though...

[kortschak]

You all are aware that issue can be moved between repos?

[kevinushey]

You all are aware that issue can be moved between repos?

I am now, thanks.

[kortschak]

Thank you.

[yihui]

@kortschak This is expected. See https://yihui.name/en/2017/11/knitr-verbatim-code-chunk/.

[kortschak]

Thanks. R never ceases to amaze me.

[yihui]

As I mentioned in the end of the post, I don't like the hacks myself, but it is unlikely that this will ever change in the future because it is not trivial to replace the document parser in knitr.

[kortschak]

Yes, I saw that and immediately thought of https://stackoverflow.com/a/1732454/1502538.

[yihui]

I'll reopen this issue to reconsider the possibility of `` `r x` `` because we have got a second vote: https://twitter.com/jtrnyc/status/1177225484922474496

[cderv]

For reference there is currently a way to have verbatim inline expression that we documented in https://bookdown.org/yihui/rmarkdown-cookbook/verbatim-code-chunks.html#show-a-verbatim-inline-expression

This would mean using

`` `r knitr::inline_expr("nrow(c()")` ``

in your document that you get in the end

`r nrow(c())`

Supporting `` `r x` `` would probably prevent this usage to work then.

[yihui]

Good point. Then we could probably consider alternative syntax like `{r expr}` and render it to `r expr` (i.e., remove the curly braces), or render ``r expr`` to `r expr` (remove the extra pair of backticks).

[atusy]

``r expr`` sounds okay to me.

OTH, `{r expr}` does not because sometimes we show examples of chunk options in this form (e.g., {r chunk-label, eval=FALSE}).

[cderv]

There could also be a pandoc inspired syntax from inline_code_attributes ?

`r expr`{.verbatim}

Currently knitr does not skip it and the inline code part is evaluated so such syntax does not work. but this has not advantage over ``r expr`` which is shorter and quite similar to the markdown form.

And this would be trully a knitr issue right ?