current_input() gives unexpected extension for quarto documents

[bergsmat]

Hi.

Please consider:

```{r}
knitr::current_input()
```

If I save this as doc1.rmd and render it, the result is

## [1] "doc1.rmd"

If I save this as doc2.qmd and render it, the result is

[1] "doc2.rmarkdown"

My expectation for the quarto file is

[1] "doc2.qmd"

I hope you agree.

---

> xfun::session_info('knitr')
R version 4.4.2 (2024-10-31)
Platform: x86_64-pc-linux-gnu
Running under: Ubuntu 24.04.1 LTS, RStudio 2024.9.1.394

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=en_US.UTF-8   
  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_1.0.1  graphics_4.4.2  grDevices_4.4.2 highr_0.11     
  knitr_1.49      methods_4.4.2   stats_4.4.2     tools_4.4.2    
  utils_4.4.2     xfun_0.49       yaml_2.3.10 

---

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.

[yihui]

That's because what knitr receives from Quarto is indeed *.rmarkdown, which is an intermediate file generated by Quarto from *.qmd, but I agree that this is surprising and perhaps we should do something about it in knitr.

[cderv]

Should we teach knitr about quarto logic ?

Or have a way for quarto to set the original input file so that knitr::current_input() returns it ?
e.g knit_concord$set(infile = ) but could this impact other processing ? Should there be another opts_knit to set ?

Though the real file knitted by knitr is this intermediate .rmarkdown which has some preprocessing in it. so regarding line number for knitr for exemple, this is the real input 🤔 so should current_input() be related to quarto input or knitr ?

FWIW there are way in Quarto to get the input file name. Not straightforward yet, but they exits

Currently using an extension: https://github.com/mcanouil/quarto-lua-env
{{< lua-env quarto.doc.input_file >}} would get the .qmd input file
Or directly in a Lua filter.

Maybe this will be exposed in the future as built-in: quarto-dev/quarto-cli#4770

@bergsmat in which context are you using current_input() by the way ? I am curious to understand the logic in quarto context. Thanks

[bergsmat]

@cderv Thanks for the question. I maintain the cran package ‘script’ (only two functions) which aims to identify the current script both interactively and non-interactively. (Combines several ideas scavenged from SO, etc.) My most common use case is to author scripts that create output files (typically csv) that have coordinated base names for traceability. I’m new to quarto but am now an enthusiastic advocate. I’d like ‘script’ to support qmd in addition to r, rmd, and rnw. Happy to abandon the package in favor of a global solution to this common problem!

[cderv]

Thanks for sharing. It makes sense !

My most common use case is to author scripts that create output files (typically csv) that have coordinated base names for traceability.

Though I am not sure you'll be able to control the output filename for a knitr evaluated content with Quarto. I may be wrong, but probably with Quarto we'll need other solution for this problem (a quarto problem really - which is language acgnostic).

Anyhow, let's see what we could do for current_input()

[bergsmat]

Thanks. I think a change to current_input() will suffice. For clarity, my intent is that script.qmd writes script.html, but also script.csv as a side effect, where script.csv is not hard-coded but is a function of the current file name.

[cderv]

Oh I see ! I missed that. yeah it would be enough

[yihui]

Thanks. I think a change to current_input() will suffice. For clarity, my intent is that script.qmd writes script.html, but also script.csv as a side effect, where script.csv is not hard-coded but is a function of the current file name.

If you only need the base name, it shouldn't matter if knitr::current_input() returns *.rmarkdown or *.qmd, right? The *.csv filename is xfun::with_ext(knitr::current_input(), '.csv').

[bergsmat]

@yihui Correct! In fact I’ve already patched script package accordingly, which works for this one use case. Still, I cannot anticipate to what other uses these functions will be applied, and one longs for programmatic access to the full path of the authored script, regardless format (qmd, r, rmd, rnw, …). If quarto and ONLY quarto ever returns .rmarkdown, perhaps we don’t have a problem. Except that my users are fond of using Rmd instead of rmd, and I can’t be sure they won’t use Qmd instead of qmd, etc. I suppose I could root around a bit in dirname() using file.exists(), but it seems a bit inelegant. Thoughts?

[cderv]

and I can’t be sure they won’t use Qmd instead of qmd,

FWIW .Qmd isn't really something supported IMO. Possibly some stuff of quarto could warn, break or not well support the uppercase. It should probably always make sure it is lower case, but not 💯 we do.

Just to precise that .Rmd was a thing (I think due to R language) but .Qmd is not.

[bergsmat]

@cderv Very good. Then for all practical purposes perhaps *.rmarkdown is a one-to-one proxy for *.qmd. I'll treat it that way until I know differently. It does make sense to me that current_input() would do similarly, but okay with me if this issue is closed without addressing.