emit progressr::progressor() progress bar from knit()

[maxheld83]

I'd like to be able to handle the progress information of knitr documents more flexibly.
I'd like to be able to determine handling/presentation of knitr progress as a caller (a design suggested by progressr).

This is closely related to:

• Rethink the progress bar #1880 (about how knitr should present progress by default)
• use a single-line progress bar, addresses #1880 #2035 (PR to implement above)
• Feature Request: Stream knitr progress to function for processing #1321 (an example of a desire to handle progress info from knit in shiny)

@cderv also raises parts of this in #2035 (comment).

I'm logging this as a separate ticket because I'm suggesting emitting progressr::progressor() in particular, potentially in addition to / independent of how knitr should present progress (~ logs?) by default.

---

Use case(s)

Rendering from Shiny

I'm writing a shiny app to programmatically create rmarkdown reports.
I'd like to pass on information about the progress of the rendering sessions to my users.

The knitr::knit(quiet = FALSE)/rmarkdown::render(quiet = FALSE) is great for developers or R users who render a single Rmarkdown document, but less so for non-technical users via shiny.

(I am aware that I can advance the shiny::Progress$new()progress bar from inside the rmarkdown document as per rstudio/shiny#1660, but this seems a little inelegant, because it's not really a concern of the rmarkdown report.)

Building on top of knitr::knit()

Separately, when building stuff on top of knitr::knit(), such as functions which create many rmarkdown reports, it would also be nice to access the progress of each of the reports.
In this case, too, both quiet = FALSE seems overwhelming.

Proposed solution

Perhaps, the fundamental limitation is that knitr::knit(quiet = FALSE)

• makes progress an "all or nothing" choice
• serves both as log and as progress bar

I seems to me that progressrs design to leave the presentation of progress bar (or whatever else you want to do with it) to the caller might make sense here to make knitr::knit() more flexible.

Therefore, I wonder if knitr::knit() could emit a progressr::progressor() object, which callers could then use as they please.
(This could be optional so as not to take on a dependency).

---

---

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.

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