VSCode: watch for changes in server preview

[pat-s]

Currently there is no easy way to start a live server which watches for input changes (similar to xaringan::inf_mr()).

My current workaround is as follows

1. quarto preview <.qmd> --no-browser
2. Open the resulting .html in an integrated vscode browser window

While this web server watches for changes, it does not change slides automatically to the one which included the last change.

It would be great if

• Starting a server/manual render would configurable via a setting
• A dedicated serve command/option would exists besides the static render functionality

[jjallaire]

Yes, these feature do in fact exist! The Quarto VS Code Extension has integrated support for quarto preview -- when you execute the Render command (Cmd+Shift+K) the preview is automatically updated. There is also support for automatically navigating to the last edited slide.

[mcanouil]

Indeed, I have been using this a lot (everytime). 😎
(although I did not check if the active slide was changed to the modified one)

[pat-s]

Thanks. I might have explained the issue badly and try to re-explain :)

Instead of having to hit cmd+shift+k every time I want a refresh and wait for the command to render the whole document again, I'd wish for a similar feature as xaringan::inf_mr() provides:

1. Render on-save (in the background without having to see all the render code flushing down the terminal), similar as it happens when previewing a website project with quarto
2. Automatically jump to the last edited slide (which is not working for me with quarto 1.0.38 or 1.1.75

(For (2) in a fresh setup I always end up at the title slide and navigation to the last edited slide does not work (extension version v1.32.0). Maybe a bug?)

[jjallaire]

Okay, I'll investigate the slide navigation issue further.

To be clear, the preview feature works the same for websites and presentations: you always need to do a render to trigger a preview (not just a save, although note that render also executes a save). We do this so that users have a choice between merely saving and doing a (potentially very expensive) save and render. If we collapsed render into save (i.e. always render on save) then saving might become something you can do very infrequently b/c it takes so long / crushes your laptop battery. This might not be applicable in your case but there are many users that have documents that take dozens of seconds or even minutes to render.

[pat-s]

To be clear, the preview feature works the same for websites and presentations: you always need to do a render to trigger a preview (not just a save, although note that render also executes a save).

Hmm now I am somewhat confused. In a website project I am working on since some weeks I usually do a quarto preview and there saving a file triggers a render. This then works as I have described it above (and actually like it). Is this then actually an undesired behavior?

For presentations it's different, there saving the qmd does not trigger a render and I need to manually render (which sounds like this is how it should be).

Wondering what might be different with my setup? 🤔 The only difference between the website and the presentation is that for the latter I need to call quarto preview <file> whereas for a website I can just do quarto preview as it seems to look for _quarto.yml.

I understand that "render on save" might not be a desired default but what about having a "render on save" side by side to a "render on manual trigger"? So that users could choose what they like depending on the heaviness of their presentation.

[mcanouil]

Just wondering, you keep talking about Quarto CLI, are you not using the extension render button?

[pat-s]

I do and I also use cmd+shift+k but also playing around with manual executions and different arguments to better understand the behavior.

[jjallaire]

Slide navigation is working for me w/ VS Code extension v1.32.0 and Quarto v1.1 Pre-Release (https://quarto.org/docs/download/prerelease.html). Perhaps something we fixed in the Pre-Release but I don't recall that being the case.

One thing to know is that slide navigation doesn't work for the very first navigation within a quarto preview session. If for some reason in your config the quarto preview isn't re-using the running quarto preview then you'd see navigation "fail". Is quarto preview getting re-started for you every time?

[pat-s]

Ahh so I've probably found the issue. First of all, it works with the example qmd in RStudio.

Apparently my qmd has some syntax issue which prevents the navigation to work.
There are no issues or warnings during render but apparently something is different compared to the template - I'll investigate.

[pat-s]

I've found something which looks like a potential bug:

Whenever there is content between the yaml header and the first ##, the navigation will always be one slide above the desired slide.
This feels like as if navigation is broken if one continues with the next slide, then renders but the preview stays at the previous one.

In my case, I had a knitr setup chunk there which triggered this behavior. Moving the chunk below the ## Quarto header solves the issue.

---
title: "Untitled"
format: revealjs
editor: visual
---

```{r setup}
knitr::opts_chunk$set(cache = TRUE)
```

## Quarto

Quarto enables you to weave together content and executable code into a finished presentation. To learn more about Quarto presentations see <https://quarto.org/docs/presentations/>.

[jjallaire]

There is a difference in behavior between quarto preview from the terminal and Cmd+Shift+K. When running preview from the terminal we do render on save (which allows us to provide a good UX for any non-Quarto aware editor by leveraging save). When running with the Render button though we know that we have the Render button to re-trigger so we pass the --no-watch-inupts argument.

RStudio actually has a check box to enable "Render on Save" however VS Code doesn't yet have such an option.

w/r/t the issue you found, this may not be easily resolvable as we are attempting to discern the slide indexes from the source code, and that code chunk appears to us as "content" (we don't know what it's doing). I think that the setup chunk in knitr is such a common idiom though that we probably should special-case that. I'll keep this issue open to track this work.

Note also that you can do the same in YAML with:

---
title: "Untitled"
format: revealjs
editor: visual
execute:
  cache: true
---

[pat-s]

Thanks!

RStudio actually has a check box to enable "Render on Save" however VS Code doesn't yet have such an option.

This might be the important part AFAICS as even when not using --no-watch-inputs the behavior on the user side is the same.

When using

• quarto preview <qmd> --no-browser: I get no browser opened and can use a custom live preview in vscode but this one is not honoring navigation and always jumps back to the title slide
• quarto preview <qmd>: My default browser opens but also without navigation support

I'll try to get use to manual rendering for now and eventually there will be a "render on save" support for vscode at some point.

Thanks for showing the cache yaml alternative!

[jjallaire]

Yes, slide navigation only works if we are managing the preview (which means use the Render button)

[blendersamsonov]

Hello,
I'm encountering the same issue, that no matter what, I never get automatically navigated back to the previously opened slide. It makes iterating on the presentation almost impossible, since you have to manually change the slides.
Setting hash: true and/or history:true as mentioned in #2175 doesn't help either.

Directly calling quarto preview from terminal or setting quarto preview to external in extension settings doesn't mess the navigation, but doesn't refresh external browser either, so it's not really a viable workaround.

I'm on Quarto version 1.5.57 and VS Code extension 1.116.0.

Any ideas, how this can be fixed again?