This PR has a set of commits to (potentially) improve etable. Here's the set of changes:
div.class is an option for setFixest_etable to match markdown.
etable(..., file = path) fails when path has a directory that doesn't exist. This PR checks for this and creates the directory if needed.
Fix a sort of nefarious bug with export. Say you have etable(..., export = path) where path is a relative directory, the directory does not exist, and markdown = FALSE. The function check_set_path will return the relative path back. However, building the png sets the working directory to tempdir(), so moving the png to path fails.
To do this, the file name is extracted if it exists (and with the fix to 3) and used as png_name.
The controversial change involves markdown processing. I can remove this one if you don't agree.
Rmarkdown and quarto (both using knitr) saves plots in knitr::fig_path() (usually X_files/figures-html/). Putting the etable pngs in here gives the benefit of allowing self_contained to process them.
Quarto/knitr has the option output.dir which lets your execution working directory differ from where the output is created. You can access this with knitr::opts_knit$get("output.dir"). This means with this option, the images produced by etable won't be in the correct location of the html document.
For example, if I have a .Rmd in a subfolder (e.g. ./vignettes/) but I want it use the main folder (./) as the working directory, etable will use ./etable/images/ instead of ./vignettes/etable/images.
By using these two functions, I think etable much better ties in with quarto/rmarkdown. I've faced this problem with my own day-to-day use of qmd, so it's not just a random edge case (or maybe I'm the edge case).
Hi Laurent,
This PR has a set of commits to (potentially) improve
etable. Here's the set of changes:div.classis an option forsetFixest_etableto matchmarkdown.etable(..., file = path)fails whenpathhas a directory that doesn't exist. This PR checks for this and creates the directory if needed.Fix a sort of nefarious bug with
export. Say you haveetable(..., export = path)wherepathis a relative directory, the directory does not exist, andmarkdown = FALSE. The functioncheck_set_pathwill return the relative path back. However, building the png sets the working directory totempdir(), so moving the png topathfails.Allowing for named exports https://github.com/lrberge/fixest/issues/451
To do this, the file name is extracted if it exists (and with the fix to 3) and used as
png_name.The controversial change involves
markdownprocessing. I can remove this one if you don't agree.plots inknitr::fig_path()(usuallyX_files/figures-html/). Putting the etable pngs in here gives the benefit of allowingself_containedto process them.Quarto/
knitrhas the optionoutput.dirwhich lets your execution working directory differ from where the output is created. You can access this withknitr::opts_knit$get("output.dir"). This means with this option, the images produced byetablewon't be in the correct location of thehtmldocument.For example, if I have a .Rmd in a subfolder (e.g.
./vignettes/) but I want it use the main folder (./) as the working directory,etablewill use./etable/images/instead of./vignettes/etable/images.By using these two functions, I think etable much better ties in with quarto/rmarkdown. I've faced this problem with my own day-to-day use of qmd, so it's not just a random edge case (or maybe I'm the edge case).