Closed apreshill closed 3 years ago
One way to achieve this is options(blogdown.use.processx = FALSE, xfun.bg_process.verbose = TRUE)
. Unfortunately, with the processx package, it's not straightforward to print messages to the console: https://github.com/r-lib/processx/issues/72.
From a user standpoint, any kind of progress or action indication would be most welcome. It doesn't have to be the actual message printed by Hugo- would it be possible to print "Change detected, rebuilding site."?
This printed when working in hugodown, and it was helpful:
On windows, if I set options(blogdown.use.processx = FALSE, xfun.bg_process.verbose = TRUE)
I get this output from Hugo by the background process. It is in another windows that opens but I currently get them. It would indeed be better in the R console directly.
It would be indeed interested if we could do the trick in hugodown, same one described in https://github.com/r-lib/processx/issues/72#issuecomment-321836648 when advice to use the later package
poll_process <- function() {
if (!ps$is_alive()) {
return()
}
out <- ps$read_output()
if (!identical(out, "")) {
cat(out)
}
later::later(delay = 1, poll_process)
}
poll_process()
This is what allow hugodown to output the background process messages into the R console. Did you already tried that @yihui ? Is later not an option ? they have private loops now that should prevent any conflict with other loops. Do you want me to try something with it tomorrow ?
@cderv Thanks! I know how to implement it. I was only saying that it was not straightforward---you have to keep polling. I was wishing for the succinct syntax process$new(stdout = "")
.
@apreshill I said almost exactly the same thing at https://github.com/r-lib/processx/issues/72#issuecomment-321840132:
It is more informative than complete silence.
Anyway, options(blogdown.use.processx = FALSE, xfun.bg_process.verbose = TRUE)
gives you what you want. It does have the problem of opening a new window on Windows as @cderv mentioned (you are on Mac so you don't have this problem), but I'm not sure if this is an advantage or disadvantage, because these Hugo messages can quickly take over the R console, and they often look similar to each other. I don't know if users would like the clutter in the R console by default. If the messages are written to a separate window, users can choose to look at the window when they want to.
These last two "changes detected" are helpful as it cues me to know there aren't any errors
When any Hugo errors occur, you will see the errors in the page preview like this: https://github.com/rstudio/blogdown/issues/546#issuecomment-752038669 If you don't see errors in the viewer/browser, you can be pretty much sure that no errors occurred.
and when to know if the preview has been updated (it is sometimes hard to see in the browser when live reload refreshes)
The message "Change detected, rebuilding site" doesn't indicate if the preview has been updated. It only says the site was rebuilt. If you feel the preview is not updated, chances are it really is not, and something else might be wrong (like #556).
@apreshill Now you can use options(blogdown.server.verbose = TRUE)
so the server messages can be printed.
@cderv I'm currently using xfun::bg_process()
when the verbose option is enabled, but I could use the method you mentioned in the future if we run into any problems. Thanks!
Ok great. Eventually, using several methods ends up being more complicated than staying with one (only processx or xfun).
This will be enough I think for a debug mode with verbosity. Thank you!
Hi @yihui,
I've been working a lot with blogdown over the past week, and realized one thing that led me to some errors introduced by over-page-refreshing. When I make changes to my site with
serve_site()
running, the only thing that prints to the console (over and over again) isblogdown:::preview_site()
. But if I'm running hugo server in the terminal I see:These last two "changes detected" are helpful as it cues me to know there aren't any errors, and when to know if the preview has been updated (it is sometimes hard to see in the browser when live reload refreshes). I was hitting page refresh often and thanks to @cderv realized this was leading me to experience more issues. Do you think something like this could print to the console as you work?