search

inbo / protocolhelper

Helper functions and templates to manage the INBO/protocols repository.
https://inbo.github.io/protocolhelper/
GNU General Public License v3.0
5 stars 0 forks source link

wegschrijven media files in convert_docx_to_rmd() #52

Closed joost-vanoverbeke closed 3 years ago

joost-vanoverbeke commented 3 years ago

in de functie convert_docx_to_rmd() lijkt er nog geen volledige afstemming waar de Rmd file wordt gesaved en waar de media files. Als ik vb. vanuit de folder (relatief tov het Rstudio project) "090_vissen/templates" convert_docx_to_rmd(from = "090_vissen/templates/template_vissen.docx", to = "template_vissen.Rmd", dir = "090_vissen/templates") run wordt de Rmd file correct onder "090_vissen/templates" gesaved, maar komen de media files onder "090_vissen/templates/090_vissen/templates/media" te staan.

Als ik daarentegen convert_docx_to_rmd(from = "090_vissen/templates/template_vissen.docx", to = "template_vissen.Rmd") run, komen de media onder de juiste directiry "090_vissen/templates/media", maar wordt de Rmd file onder mijn home folder opgeslagen.

hansvancalster commented 3 years ago

Bedankt om dit te melden. Ik vermoed dat het correct zal werken indien je in dir = ... een absoluut path doorgeeft. Dat doe je dan best mbv rprojroot::find_root_file() of iets dergelijks (zodat het reproduceerbaar wordt op verschillende machines).

@ElsLommelen als bovenstaande werkt, dient misschien enkel de documentatie aangepast te worden? Een andere optie is de functie gebruiksvriendelijker maken zodat het ook (?) werkt met een relatief path. Persoonlijk vermijd ik liever gebruik van relatieve paden en werk daarom meestal via rprojroot package.

Als ik daarentegen convert_docx_to_rmd(from = "090_vissen/templates/template_vissen.docx", to = "template_vissen.Rmd") run, komen de media onder de juiste directiry "090_vissen/templates/media", maar wordt de Rmd file onder mijn home folder opgeslagen.

Als je niets opgeeft bij dir, wordt dir = "." (current working directory). Vermits je current working directory je home folder is, was je mogelijk niet in en Rstudio project aan het werken?

joost-vanoverbeke commented 3 years ago

Jawel hoor,

ik was in een Rstudio project aan het werken.

https://github.com/inbo/moneos/blob/joost-090-vissen/090_vissen/templates/word_naar_rmd.R

geopend op mijn pc onder het Rstudio project 'moneos'

hansvancalster commented 3 years ago

Ik kan dit voorlopig niet reproduceren. In de volgende test lijkt mij alles te werken naar verwachting:

library(protocolhelper)
library(rprojroot)
library(fs)
setwd("C:/R/temp/test_convert_docx")
convert_docx_to_rmd(from = "SVP_401_VegetatieOpnamePV_Terrestrisch_v1.1.docx",
                    to = "sfp-401-nl.Rmd",
                    dir = find_root_file("converted", criterion = is_rstudio_project))
#> [1] "C:/R/temp/test_convert_docx/converted/sfp-401-nl.Rmd"
convert_docx_to_rmd(from = "SVP_401_VegetatieOpnamePV_Terrestrisch_v1.1.docx",
                    to = "sfp-401-nl.Rmd",
                    dir = "converted2")
#> [1] "converted2/sfp-401-nl.Rmd"

convert_docx_to_rmd(from = "SVP_401_VegetatieOpnamePV_Terrestrisch_v1.1.docx",
                    to = "sfp-401-nl.Rmd")
#> [1] "./sfp-401-nl.Rmd"

dir_tree()
#> .
#> +-- converted
#> |   +-- media
#> |   |   +-- image1.png
#> |   |   +-- image10.png
#> |   |   +-- image11.emf
#> |   |   +-- image12.png
#> |   |   +-- image13.png
#> |   |   +-- image14.png
#> |   |   +-- image15.png
#> |   |   +-- image16.png
#> |   |   +-- image17.png
#> |   |   +-- image18.png
#> |   |   +-- image19.png
#> |   |   +-- image2.jpeg
#> |   |   +-- image20.png
#> |   |   +-- image21.png
#> |   |   +-- image22.png
#> |   |   +-- image4.png
#> |   |   +-- image5.png
#> |   |   +-- image6.jpeg
#> |   |   +-- image7.png
#> |   |   +-- image8.jpeg
#> |   |   \-- image9.jpeg
#> |   \-- sfp-401-nl.Rmd
#> +-- converted2
#> |   +-- media
#> |   |   +-- image1.png
#> |   |   +-- image10.png
#> |   |   +-- image11.emf
#> |   |   +-- image12.png
#> |   |   +-- image13.png
#> |   |   +-- image14.png
#> |   |   +-- image15.png
#> |   |   +-- image16.png
#> |   |   +-- image17.png
#> |   |   +-- image18.png
#> |   |   +-- image19.png
#> |   |   +-- image2.jpeg
#> |   |   +-- image20.png
#> |   |   +-- image21.png
#> |   |   +-- image22.png
#> |   |   +-- image4.png
#> |   |   +-- image5.png
#> |   |   +-- image6.jpeg
#> |   |   +-- image7.png
#> |   |   +-- image8.jpeg
#> |   |   \-- image9.jpeg
#> |   \-- sfp-401-nl.Rmd
#> +-- media
#> |   +-- image1.png
#> |   +-- image10.png
#> |   +-- image11.emf
#> |   +-- image12.png
#> |   +-- image13.png
#> |   +-- image14.png
#> |   +-- image15.png
#> |   +-- image16.png
#> |   +-- image17.png
#> |   +-- image18.png
#> |   +-- image19.png
#> |   +-- image2.jpeg
#> |   +-- image20.png
#> |   +-- image21.png
#> |   +-- image22.png
#> |   +-- image4.png
#> |   +-- image5.png
#> |   +-- image6.jpeg
#> |   +-- image7.png
#> |   +-- image8.jpeg
#> |   \-- image9.jpeg
#> +-- sfp-401-nl.Rmd
#> +-- SVP_401_VegetatieOpnamePV_Terrestrisch_v1.1.docx
#> +-- testje.R
#> \-- test_convert_docx.Rproj

Created on 2021-06-15 by the reprex package (v2.0.0)

Session info ``` r sessioninfo::session_info() #> - Session info --------------------------------------------------------------- #> setting value #> version R version 4.1.0 (2021-05-18) #> os Windows 10 x64 #> system x86_64, mingw32 #> ui RTerm #> language (EN) #> collate Dutch_Belgium.1252 #> ctype Dutch_Belgium.1252 #> tz Europe/Paris #> date 2021-06-15 #> #> - Packages ------------------------------------------------------------------- #> package * version date lib source #> assertthat 0.2.1 2019-03-21 [1] CRAN (R 4.1.0) #> bookdown 0.22 2021-04-22 [1] CRAN (R 4.1.0) #> cli 2.5.0 2021-04-26 [1] CRAN (R 4.1.0) #> commonmark 1.7 2018-12-01 [1] CRAN (R 4.1.0) #> crayon 1.4.1 2021-02-08 [1] CRAN (R 4.1.0) #> digest 0.6.27 2020-10-24 [1] CRAN (R 4.1.0) #> evaluate 0.14 2019-05-28 [1] CRAN (R 4.1.0) #> fs * 1.5.0 2020-07-31 [1] CRAN (R 4.1.0) #> glue 1.4.2 2020-08-27 [1] CRAN (R 4.1.0) #> highr 0.9 2021-04-16 [1] CRAN (R 4.1.0) #> htmltools 0.5.1.1 2021-01-22 [1] CRAN (R 4.1.0) #> knitr 1.33 2021-04-24 [1] CRAN (R 4.1.0) #> magrittr 2.0.1 2020-11-17 [1] CRAN (R 4.1.0) #> protocolhelper * 0.2.0 2021-06-07 [1] Github (inbo/protocolhelper@cc45ba1) #> ps 1.6.0 2021-02-28 [1] CRAN (R 4.1.0) #> purrr 0.3.4 2020-04-17 [1] CRAN (R 4.1.0) #> reprex 2.0.0 2021-04-02 [1] CRAN (R 4.1.0) #> rlang 0.4.11 2021-04-30 [1] CRAN (R 4.1.0) #> rmarkdown 2.8 2021-05-07 [1] CRAN (R 4.1.0) #> rprojroot * 2.0.2 2020-11-15 [1] CRAN (R 4.1.0) #> rstudioapi 0.13 2020-11-12 [1] CRAN (R 4.1.0) #> sessioninfo 1.1.1 2018-11-05 [1] CRAN (R 4.1.0) #> stringi 1.6.1 2021-05-10 [1] CRAN (R 4.1.0) #> stringr 1.4.0 2019-02-10 [1] CRAN (R 4.1.0) #> withr 2.4.2 2021-04-18 [1] CRAN (R 4.1.0) #> xfun 0.23 2021-05-15 [1] CRAN (R 4.1.0) #> xml2 1.3.2 2020-04-23 [1] CRAN (R 4.1.0) #> yaml 2.2.1 2020-02-01 [1] CRAN (R 4.1.0) #> ymlthis 0.1.4 2021-03-23 [1] CRAN (R 4.1.0) #> #> [1] C:/R/library #> [2] C:/R/R-4.1.0/library ```
ElsLommelen commented 3 years ago

@hansvancalster Ik vermoed dat je de map in kwestie ook moet toevoegen aan from, probeer dit eens:

library(protocolhelper)
setwd("C:/R/temp")
convert_docx_to_rmd(from = "test_convert_docx/SVP_401_VegetatieOpnamePV_Terrestrisch_v1.1.docx",
                    to = "sfp-401-nl.Rmd",
                    dir = "test_convert_docx")
ElsLommelen commented 3 years ago

Als ik daarentegen convert_docx_to_rmd(from = "090_vissen/templates/template_vissen.docx", to = "template_vissen.Rmd") run, komen de media onder de juiste directiry "090_vissen/templates/media", maar wordt de Rmd file onder mijn home folder opgeslagen.

Als je niets opgeeft bij dir, wordt dir = "." (current working directory). Vermits je current working directory je home folder is, was je mogelijk niet in en Rstudio project aan het werken?

@hansvancalster Akkoord dat onder een RStudio project werken veel zou oplossen. Anderzijds is het toch niet echt logisch dat het bestand zelf opgeslagen wordt in de wd, en de folder met bijhorende figuren in de map die vermeld staat bij from. Bij voorkeur zouden die in dezelfde folder opgeslagen worden (en de map zou dus best volgens hetzelfde systeem bepaald worden)...

Ook lijkt het mij handig, moesten de figuren in het bestand relatieve paden krijgen (handig bij samenwerking via github), maar da's een andere discussie.

hansvancalster commented 3 years ago

Als ik het docx bestand in dezelfde directory plaats waar de output naartoe wordt geschreven werkt het goed in het geval van gebruik van rprojroot (welke een absolute padverwijzing geeft), maar inderdaad bij relatieve padverwijzing loopt het dan mis:

library(protocolhelper)
library(rprojroot)
library(fs)
setwd("C:/R/temp/test_convert_docx")

convert_docx_to_rmd(
  from = find_root_file(
    "converted/SVP_401_VegetatieOpnamePV_Terrestrisch_v1.1.docx",
    criterion = is_rstudio_project
  ),
  to = "sfp-401-nl.Rmd",
  dir = find_root_file(
    "converted", 
    criterion = is_rstudio_project
  )
)
#> [1] "C:/R/temp/test_convert_docx/converted/sfp-401-nl.Rmd"

convert_docx_to_rmd(
  from = "converted2/SVP_401_VegetatieOpnamePV_Terrestrisch_v1.1.docx",
  to = "sfp-401-nl.Rmd",
  dir = "converted2"
)
#> [1] "converted2/sfp-401-nl.Rmd"

convert_docx_to_rmd(
  from = "SVP_401_VegetatieOpnamePV_Terrestrisch_v1.1.docx",
  to = "sfp-401-nl.Rmd"
)
#> [1] "./sfp-401-nl.Rmd"

dir_tree()
#> .
#> +-- converted
#> |   +-- media
#> |   |   +-- image1.png
#> |   |   +-- image10.png
#> |   |   +-- image11.emf
#> |   |   +-- image12.png
#> |   |   +-- image13.png
#> |   |   +-- image14.png
#> |   |   +-- image15.png
#> |   |   +-- image16.png
#> |   |   +-- image17.png
#> |   |   +-- image18.png
#> |   |   +-- image19.png
#> |   |   +-- image2.jpeg
#> |   |   +-- image20.png
#> |   |   +-- image21.png
#> |   |   +-- image22.png
#> |   |   +-- image4.png
#> |   |   +-- image5.png
#> |   |   +-- image6.jpeg
#> |   |   +-- image7.png
#> |   |   +-- image8.jpeg
#> |   |   \-- image9.jpeg
#> |   +-- sfp-401-nl.Rmd
#> |   \-- SVP_401_VegetatieOpnamePV_Terrestrisch_v1.1.docx
#> +-- converted2
#> |   +-- converted2
#> |   |   \-- media
#> |   |       +-- image1.png
#> |   |       +-- image10.png
#> |   |       +-- image11.emf
#> |   |       +-- image12.png
#> |   |       +-- image13.png
#> |   |       +-- image14.png
#> |   |       +-- image15.png
#> |   |       +-- image16.png
#> |   |       +-- image17.png
#> |   |       +-- image18.png
#> |   |       +-- image19.png
#> |   |       +-- image2.jpeg
#> |   |       +-- image20.png
#> |   |       +-- image21.png
#> |   |       +-- image22.png
#> |   |       +-- image4.png
#> |   |       +-- image5.png
#> |   |       +-- image6.jpeg
#> |   |       +-- image7.png
#> |   |       +-- image8.jpeg
#> |   |       \-- image9.jpeg
#> |   +-- sfp-401-nl.Rmd
#> |   \-- SVP_401_VegetatieOpnamePV_Terrestrisch_v1.1.docx
#> +-- media
#> |   +-- image1.png
#> |   +-- image10.png
#> |   +-- image11.emf
#> |   +-- image12.png
#> |   +-- image13.png
#> |   +-- image14.png
#> |   +-- image15.png
#> |   +-- image16.png
#> |   +-- image17.png
#> |   +-- image18.png
#> |   +-- image19.png
#> |   +-- image2.jpeg
#> |   +-- image20.png
#> |   +-- image21.png
#> |   +-- image22.png
#> |   +-- image4.png
#> |   +-- image5.png
#> |   +-- image6.jpeg
#> |   +-- image7.png
#> |   +-- image8.jpeg
#> |   \-- image9.jpeg
#> +-- sfp-401-nl.Rmd
#> +-- SVP_401_VegetatieOpnamePV_Terrestrisch_v1.1.docx
#> +-- testje.R
#> \-- test_convert_docx.Rproj

Created on 2021-06-15 by the reprex package (v2.0.0)

Session info ``` r sessioninfo::session_info() #> - Session info --------------------------------------------------------------- #> setting value #> version R version 4.1.0 (2021-05-18) #> os Windows 10 x64 #> system x86_64, mingw32 #> ui RTerm #> language (EN) #> collate Dutch_Belgium.1252 #> ctype Dutch_Belgium.1252 #> tz Europe/Paris #> date 2021-06-15 #> #> - Packages ------------------------------------------------------------------- #> package * version date lib source #> assertthat 0.2.1 2019-03-21 [1] CRAN (R 4.1.0) #> bookdown 0.22 2021-04-22 [1] CRAN (R 4.1.0) #> cli 2.5.0 2021-04-26 [1] CRAN (R 4.1.0) #> commonmark 1.7 2018-12-01 [1] CRAN (R 4.1.0) #> crayon 1.4.1 2021-02-08 [1] CRAN (R 4.1.0) #> digest 0.6.27 2020-10-24 [1] CRAN (R 4.1.0) #> evaluate 0.14 2019-05-28 [1] CRAN (R 4.1.0) #> fs * 1.5.0 2020-07-31 [1] CRAN (R 4.1.0) #> glue 1.4.2 2020-08-27 [1] CRAN (R 4.1.0) #> highr 0.9 2021-04-16 [1] CRAN (R 4.1.0) #> htmltools 0.5.1.1 2021-01-22 [1] CRAN (R 4.1.0) #> knitr 1.33 2021-04-24 [1] CRAN (R 4.1.0) #> magrittr 2.0.1 2020-11-17 [1] CRAN (R 4.1.0) #> protocolhelper * 0.2.0 2021-06-07 [1] Github (inbo/protocolhelper@cc45ba1) #> ps 1.6.0 2021-02-28 [1] CRAN (R 4.1.0) #> purrr 0.3.4 2020-04-17 [1] CRAN (R 4.1.0) #> reprex 2.0.0 2021-04-02 [1] CRAN (R 4.1.0) #> rlang 0.4.11 2021-04-30 [1] CRAN (R 4.1.0) #> rmarkdown 2.8 2021-05-07 [1] CRAN (R 4.1.0) #> rprojroot * 2.0.2 2020-11-15 [1] CRAN (R 4.1.0) #> rstudioapi 0.13 2020-11-12 [1] CRAN (R 4.1.0) #> sessioninfo 1.1.1 2018-11-05 [1] CRAN (R 4.1.0) #> stringi 1.6.1 2021-05-10 [1] CRAN (R 4.1.0) #> stringr 1.4.0 2019-02-10 [1] CRAN (R 4.1.0) #> withr 2.4.2 2021-04-18 [1] CRAN (R 4.1.0) #> xfun 0.23 2021-05-15 [1] CRAN (R 4.1.0) #> xml2 1.3.2 2020-04-23 [1] CRAN (R 4.1.0) #> yaml 2.2.1 2020-02-01 [1] CRAN (R 4.1.0) #> ymlthis 0.1.4 2021-03-23 [1] CRAN (R 4.1.0) #> #> [1] C:/R/library #> [2] C:/R/R-4.1.0/library ```
ElsLommelen commented 3 years ago

Als ik het docx bestand in dezelfde directory plaats waar de output naartoe wordt geschreven werkt het goed in het geval van gebruik van rprojroot (welke een absolute padverwijzing geeft), maar inderdaad bij relatieve padverwijzing loopt het dan mis:

Zou dit bij een relatieve padverwijzing niet opgelost kunnen worden door er intern in de functie een absolute padverwijzing van te maken, bv. door het resultaat van getwd() te gebruiken (die je opneemt als argument in de functie)? Of werkt het in de gebruikte functie van redoc wel goed, en volstaat het om de wd door te geven in convert_docx_to_rmd()?

hansvancalster commented 3 years ago

@hansvancalster Akkoord dat onder een RStudio project werken veel zou oplossen. Anderzijds is het toch niet echt logisch dat het bestand zelf opgeslagen wordt in de wd, en de folder met bijhorende figuren in de map die vermeld staat bij from. Bij voorkeur zouden die in dezelfde folder opgeslagen worden (en de map zou dus best volgens hetzelfde systeem bepaald worden)

Inderdaad. Dat wordt best aangepast.

Ook lijkt het mij handig, moesten de figuren in het bestand relatieve paden krijgen (handig bij samenwerking via github), maar da's een andere discussie.

Blijkbaar is het zo dat als je met relatieve padverwijzingen werkt, de figuren in de Rmd ook met relatieve padverwijzingen aangegeven worden. Wanneer je absolute padverwijzingen gebruikt is dat niet zo. Voor de omzetting van docx protocols los ik dat op met behulp van een interne functie uit het protocolhelper package (protocolhelper:::create_from_docx). Zie https://github.com/inbo/protocolhelper/blob/cc45ba1411bffdf59f8a062fefd22880896ab747/R/create_protocol.R#L735-L736

@ElsLommelen kan jij een voorstel doen van aanpassingen?

hansvancalster commented 3 years ago

Zou dit bij een relatieve padverwijzing niet opgelost kunnen worden door er intern in de functie een absolute padverwijzing van te maken, bv. door het resultaat van getwd() te gebruiken (die je opneemt als argument in de functie)? Of werkt het in de gebruikte functie van redoc wel goed, en volstaat het om de wd door te geven in convert_docx_to_rmd()?

Kan ik niet direct op antwoorden zonder te debuggen. Kan jij het bekijken? Misschien ook een optie om protocolhelper:::create_from_docx te exporteren en die te gebruiken (maar daar zitten dan wel een aantal voorafnames aan vast specifiek voor protocols, zoals aparte Rmd voor elk hoofdstuk)?

ElsLommelen commented 3 years ago

Ik zal eens uitpluizen wat de beste optie is en een voorstel doen.

ElsLommelen commented 3 years ago

Ik heb intussen kunnen achterhalen waar de problemen zitten, maar ik zie ook meerdere opties om dit op te lossen. Dus mss best even bekijken wat het handigst zou zijn.

Dus momenteel zijn er 3 argumenten om te bepalen waar de .Rmd en /media terechtkomen: from, to en dir.

Dit is een vrij ingewikkelde puzzel, en vooral het feit dat bij het invullen van to beiden op een andere plaats terechtkomen, lijkt me minder logisch voor een gebruiker. Enkele voorstellen om dit op te lossen:

Wat zou het meest logisch zijn en het gemakkelijkst in gebruik? (Geef gerust andere alternatieven.)

hansvancalster commented 3 years ago

Mijn 5 cent:

Dat lijkt mij het eenvoudigst. Als het echt nodig is om de media folder ergens anders terecht te laten komen, kan dat ofwel achteraf (manueel of met code), ofwel een extra argument toevoegen waarbij de default resulteert in bovenstaande.

hansvancalster commented 3 years ago

Bedankt om deze puzzel te ontwarren @ElsLommelen !

ElsLommelen commented 3 years ago

Voor to is de default om de naam EN path van from over te nemen. Ik ben akkoord met die default (om ook die locatie over te nemen), maar ik vind het een beetje raar (en vooral niet intuïtief) dat bij het opgeven van een dir hierbij het path plots een combinatie wordt van from en dir. Dus als je je resultaat niet wilt opslaan in een path dat begint met from, ben je sowieso verplicht om to op te geven, zelfs als je de naam van je docx wil behouden. En volgens de documentatie mag je daar enkel een filename opgeven (terwijl een path wel zou werken, vermoed ik), dus in dat geval moet je nog eens een extra argument dir toevoegen als je je path anders wil dan de wd.

Om te implementeren is dat voorstel inderdaad het eenvoudigst vanuit de huidige situatie, maar voor een gebruiker is het toch wel serieus puzzelen als je niet gewoon de default wil dat je een Rmd opslaat op dezelfde plaats als waar de docx staat: je moet er sowieso aan denken om to in te vullen, anders krijg je default je from-path + je dir-path. En eigenlijk is uit de documentatie ook helemaal niet duidelijk dat dit default zo gebeurt... (En mss wil je zelfs een warning geven in gevallen dat een counter-intuïtieve default gebruikt wordt?)

Volgens het KISS-principe zou ik denken: probeer die argumenten onafhankelijk te maken van elkaar. Ok om een default te hebben die gewoon alles opslaat waar ook de input staat, maar die interactie tussen to en dir is minder intuïtief en zou volgens mij beter vervangen door een argument dat de locatie en/of naam van de .Rmd bepaalt (evt. 2 argumenten, of 1 dat naam en/of path kan afhandelen, dus gebruiker geeft ofwel een path (waarbij naam van from wordt overgenomen), ofwel path + file), en liefst ook een dat de locatie van /media bepaalt (enkel in te vullen als afwijkend van waar .Rmd komt). Je zou die inderdaad achteraf manueel kunnen verplaatsen, maar dan moet je alle links naar figuren aanpassen terwijl pandoc_convert() dit netjes in orde gebracht had?

hansvancalster commented 3 years ago

Oplossing 1:

Oplossing 2:

De tweede oplossing is misschien eleganter, maar breekt een deel van de code in de create_* functies van het package (niets onoplosbaar).

ElsLommelen commented 3 years ago

De tweede oplossing vind ik ook handiger (en vaak dichter aansluitend bij de praktijk) in de zin dat de default bij weglaten van to (en dir) gewoon de gegevens van from overneemt. Dus alles wordt samen opgeslagen met de input. Bij de eerste oplossing gaat het resultaat in de wd terechtkomen als je enkel from invult, wat waarschijnlijk minder vaak gewenst is, omdat dit script met de routinecode vaak niet in je bookdown-folder zelf zit (vermoed ik).

Bij oplossing 2, default voor dir_media default gelijk aan dirname(from) als to niet ingevuld is?

Ik heb dus een lichte voorkeur voor oplossing 2, vooral omdat de default iets praktijkgerichter ingevuld kan worden, maar ook omdat ik het handiger vind als een path en bestandsnaam in 1 argument doorgegeven kan worden (als ze beiden aangepast moeten worden).

hansvancalster commented 3 years ago

OK, dan implementeren we oplossing 2.

Ik denk dat je de defaults bij de functie-argumenten zelf kan ingeven in plaats van ze leeg te laten. Zoiets:

function(
   from, 
   to = sub("docx$", "Rmd", from),
   dir_media = dirname(to)
) {
   assertthat(is.string(from), grepl("docx$", from))
}
ElsLommelen commented 3 years ago

Ja, dat kan idd, ik vroeg me al af waarom je dit niet deed.

Ok, dan zal ik de functie in die zin aanpassen.

hansvancalster commented 3 years ago

Opgelost in #53