add html_vignette function

[jangorecki]

Looking at the internal knitr:::html_vignette it looks like *_vignette functions are just a wrapper over html document function.

Could we have such function added to markdown package? and exported? @yihui

The aim is to use it in vignettes, so to specify engine as knitr::knitr, which then uses markdown (hopefully supporting toc: true, number_sections: true?).

The function will allow to reduce dependencies from 30 (or 27 because 3 deps are common with knitr)

 [1] "bslib"       "evaluate"    "fontawesome" "htmltools"   "jquerylib"  
 [6] "jsonlite"    "knitr"       "stringr"     "tinytex"     "xfun"       
[11] "yaml"        "base64enc"   "cachem"      "memoise"     "mime"       
[16] "rlang"       "sass"        "digest"      "ellipsis"    "fastmap"    
[21] "highr"       "cli"         "glue"        "lifecycle"   "magrittr"   
[26] "stringi"     "vctrs"       "fs"          "R6"          "rappdirs"

to only 2 (or 1 because 1 dep is common with knitr)

[1] "commonmark" "xfun" 

[jangorecki]

It seems that such a change would allow to build Rmd vignettes without even C++ compiler installed, as none of the deps of knitr and markdown uses C++. Whatever compiled code is there it seems to be C only.
That translates to a more lightweight build environment for R packages not having any compiled code, or having only C compiled code, as their environment does not need to have C++ compiler anymore.

[yihui]

There is no need to add a vignette format in the markdown package. You can change the vignette engine from knitr::rmarkdown (for example) to knitr::knitr to avoid the dependency on rmarkdown and only use markdown, e.g.,

markdown/vignettes/intro.Rmd

Line 15 in d4fe00c

%\VignetteEngine{knitr::knitr}

This will reduce a lot of indirect dependencies because rmarkdown has a lot of them, but note that you cannot avoid the dependency on knitr (which has become much lighter), so the actual dependencies will be: knitr, evaluate, highr, yaml, xfun, and commonmark.

hopefully supporting toc: true, number_sections: true?

Yes, these two features are supported, e.g.,

markdown/vignettes/intro.Rmd

Lines 5 to 10 in d4fe00c

	output:
	markdown::html_format:
	options:
	toc:
	depth: 4
	number_sections: true

Docs:

• https://cran.r-project.org/web/packages/markdown/vignettes/intro.html#number-sections
• https://cran.r-project.org/web/packages/markdown/vignettes/intro.html#toc

[jangorecki]

Yes, it could be consider this closed, unless...

you would be willing to provide a wrapper markdown::html_vignette for consistency to other rendering engines, maybe unroll options, so the actual change needed for users is just removing single r letter in output:.

[yihui]

That's an appealing proposal. Let me think more about it. Thanks!

[jangorecki]

having this, it will finally feel as feature complete ;)

[yihui]

Done now. Thanks again!

BTW (off-topic), personally I feel very concerned by the current status of data.table. I'd strongly recommend that the new team can get 1.14.10 released soon and complete the transfer of maintainership. You will have plenty of time to discuss the rest of issues, but the CRAN check failures really need to be addressed right now (literally). I guess the only reason that this package has not been archived is that it has a large number of reverse dependencies, and CRAN can't just kill them all, otherwise they would have archived it several months ago. I have never seen a package that can survive for so long on CRAN with check errors before. If there are any issues blocking the 1.14.10 release, you can use temporary workarounds. For example, if certain tests are failing and you can't figure out how to fix them, it's fine to simply disable these tests for the 1.14.10 release. The top priority is to make sure data.table can continue to safely stay on CRAN, and make CRAN maintainers happy. Losing the "CRAN credit" is dangerous for package maintainers.

[yihui]

FYI the new version is on CRAN now. You can use markdown:::html_vignette if you want. Someday you may even be able to get rid of the dependency on knitr, since I may provide a simple knit() function in the markdown package.

[jangorecki]

Thanks. Eliminating knitr would be great as well, it is now the most heavy dependency for data.table. Although I am happy it is not c++ so compilation time is rather minimal.