Open hadley opened 1 year ago
I think that fits well into knitr, especially if we can make the addition conditional. It seems to me that when rlang_error
and other class are used, it means rlang is available, and it does not require to have a new dependency for now.
IMO that definitely worth it to make all this available in our tool without the workaround in other package. Better traceback from knitting step will benefit users.
@hadley IIUC you are planning to entrace all errors and all warnings?
If it's only the rlang conditions (thrown via cli::cli_abort()
and cli::cli_warn()
) then I'd prefer to keep the methods in rlang to make updates easier and reduce the interdependency. If this includes base conditions, then knitr needs to own the methods and call into rlang. But we probably still want to abstract that behind an API so that the bulk of the implementation lives in rlang.
@lionel- all errors and warnings
I wrote some more thoughts in https://github.com/r-lib/rlang/issues/1551#issuecomment-1425567250
Currently, rlang includes some custom hooks to ensure that we give high-quality error tracebacks inside Rmds (implemented in https://github.com/r-lib/rlang/pull/1215). We implemented this in rlang for expediency, but I wonder if it's time to move this to knitr?
Similarly, we have been considering ways to make it easier to find where warnings occurred by supplying full backtraces. We have all the machinery to make this work, we just need to add a similar
sew()
method for warnings. Is this something that might also live in knitr?By filing an issue to this repo, I promise that
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')
.I understand that my issue may be closed if I don't fulfill my promises.