Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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 literal r code within formatted fenced code #11810

Closed
jtlandis opened this issue Jan 7, 2025 · 6 comments
Closed

Inline literal r code within formatted fenced code #11810

jtlandis opened this issue Jan 7, 2025 · 6 comments
Labels
knitr support a request for support

Comments

@jtlandis
Copy link

jtlandis commented Jan 7, 2025

Bug description

I am unsure how deep this bug goes, but this was discovered trying to use literal typst formatting for R code. The reason being that attempting to syntax highlight with typst they expect the following ```r 1 + 1```, thus the .qmd format would look something like ```` ```r 1 + 1``` ````{=typst}

However, there is a very odd bug when trying to place fenced computed code within a literal formatted code while another fenced r block exists in the file. This seems to be an issue specifically with r computed code, as this issue does not arise with python (even when using knitr engine).

Steps to reproduce

---
title: example1
format: typst
keep-typ: true
---

inline code:  ````  ```r 1 + 1```  ````{=typst}

```{r}
1 + 1
```

Which will yield a .typ file such as:

inline code: ``2``

#block[
```r
1 + 1
```

#block[
```
[1] 2
```

However omitting the fenced R block (specifically the ```{r} ... ``` pattern):

---
title: example2
format: typst
keep-typ: true
---

inline code:  ````  ```r 1 + 1```  ````{=typst}

will yield the expected .typ file output:

inline code: ```r 1 + 1```

Expected behavior

example1 should yield a .typ file with:

inline code: ```r 1 + 1```

#block[
```r
1 + 1
```

#block[
```
[1] 2
```

Actual behavior

See above

Your environment

  • Rendered through command line (outside of RStudio)
  • OS: MacOS 13.7.2

Quarto check output

Quarto 1.5.57
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.2.0: OK
      Dart Sass version 1.70.0: OK
      Deno version 1.41.0: OK
      Typst version 0.11.0: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 1.5.57
      Path: /Applications/quarto/bin

[✓] Checking tools....................OK
      TinyTeX: (external install)
      Chromium: (not installed)

[✓] Checking LaTeX....................OK
      Using: TinyTex
      Path: /Users/jtlandis/Library/TinyTeX/bin/universal-darwin
      Version: 2024

[✓] Checking basic markdown render....OK

[✓] Checking Python 3 installation....OK
      Version: 3.11.7
      Path: /Library/Frameworks/Python.framework/Versions/3.11/bin/python3
      Jupyter: 5.7.2
      Kernels: python3, ark

[✓] Checking Jupyter engine render....OK

[✓] Checking R installation...........OK
      Version: 4.4.1
      Path: /Library/Frameworks/R.framework/Resources
      LibPaths:
        - /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library
      knitr: 1.48
      rmarkdown: 2.29

[✓] Checking Knitr engine render......OK
@jtlandis jtlandis added the bug Something isn't working label Jan 7, 2025
@cscheid
Copy link
Collaborator

cscheid commented Jan 7, 2025

This isn't really a bug in quarto. The ``2`` output you're seeing comes from knitr itself (keep-md: true will show it).

Removing the fenced code block means that Quarto's automatic engine detection doesn't kick in, and so you get the "markdown" engine which doesn't do anything.

@cderv might know how to get knitr to ignore some code cells.

@cscheid cscheid added knitr support a request for support and removed bug Something isn't working labels Jan 7, 2025
@mcanouil
Copy link
Collaborator

mcanouil commented Jan 7, 2025

I believe you need to use `r knitr::inline_expr("2 + 2")` to get inline R code in knitr, but knitr::inline_expr would need to know the syntax for Typst which it currently does not.
You can see it used in all the RMarkdown Cookbook: https://bookdown.org/yihui/rmarkdown-cookbook

To note, this is definitely not a bug, that's a long time knitr behaviour independent of Quarto.

CodeHTML Page
...


````md
```{r}`r ''`
x <- 5  # radius of a circle
```

For a circle with the radius `r knitr::inline_expr('x')`,
its area is `r knitr::inline_expr('pi * x^2')`.
````

...
Image

@mcanouil
Copy link
Collaborator

mcanouil commented Jan 7, 2025

This being said, since Quarto harmonised the inline syntax with brackets: `{r} 1 + 1`
@cscheid Could the dot language also exist inline? `{.r} 1 + 1`

Note that Pandoc syntax for this is `1 + 1`{.r} which works for all formats, including Typst.

https://pandoc.org/MANUAL.html#highlighting

InputOutput
---
title: "Quarto Playground"
format: typst
engine: knitr
---

This is a playground for Quarto with inline `1 + 1`{.r} code.
Image

@cderv
Copy link
Collaborator

cderv commented Jan 7, 2025

Note that Pandoc syntax for this is 1 + 1{.r} which works for all formats, including Typst.

This is indeed the official syntax for highlighting inline code in typst. It will produce this raw code

#raw(lang:"r", "1 + 1")

This could also be used directly

inline code:  `#raw(lang:"r", "1 + 1")`{=typst}

This #raw it the typst way for inline code with language: https://typst.app/docs/reference/text/raw/

I believe you need to use r knitr::inline_expr("2 + 2") to get inline R code in knitr, but knitr::inline_expr would need to know the syntax for Typst which it currently does not.

inline_expr() is to be able to show in output the inline R syntax for knitr without evaluating it. It is a trick to be able to write ``` `r 1 +1` ``` in Markdown.

The problem here is indeed because `r .. ` is a knitr syntax for inline code to execute. And same trick than inline_expr() needs to be used but it is not a matter of support, just a custom function for evaluating code that will write the right markdown

This would like this

---
title: example1
format: typst
keep-typ: true
keep-md: true
---

```{r}
#| echo: false
raw_inline <- function(x, lang, format) {
  sprintf("```` ```%s %s ``` ````{=%s}", lang, x, format)
}
```


inline code:  `r raw_inline("1 + 1", "r", "typst")`

```{r}
1 + 1
```

So in conclusion, this is unfortunate conflict between knitr syntax and Typst syntax, and how knitr works to parse document.

So there are workaround fortunately

  • Pandoc syntax with class one inline code
  • Using raw inline with other typst syntax
  • Using a wrapper R function to write the expected markdown using the conflicted syntax

One big change we could try do in the future, it introduce an option in knitr to allow quarto to completely deactivate original knitr inline syntax to only support the Quarto inline syntax

`{r} 1 + 1`

It is an evolution to make in knitr and Quarto if we want to go this road.

Hope this clarify the problem here.

@jtlandis
Copy link
Author

jtlandis commented Jan 8, 2025

Thank you all for the quick replies! I love the explanations!

I truly wanted to have some inline syntax highlighting for my presentation, and I ended up doing something of the following to cut down on having overly verbose markdown syntax

```{=typst}
#set raw(lang: "r")
```

And then I wrote a quarto filter to inject #set raw(lang: none) in front of any pandoc div containing the .cell-output class.

I will go ahead and close the issue, thanks again!

@jtlandis jtlandis closed this as completed Jan 8, 2025
@mcanouil mcanouil closed this as not planned Won't fix, can't repro, duplicate, stale Jan 8, 2025
@mcanouil
Copy link
Collaborator

mcanouil commented Jan 8, 2025

I’m converting to discussions for better discovery in the future.

Could you share your filter for others?

@mcanouil mcanouil converted this issue into discussion #11820 Jan 8, 2025

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
knitr support a request for support
Projects
None yet
Development

No branches or pull requests

4 participants