We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In case the watch feature is enabled and we run one of the following commands
watch
mdbook serve --open mdbook watch --open
listening for file changes is blocked until the browser is closed.
Should we open the browser in a separate thread and start listening for changes immediately?
See PR (#1638) for example.
The text was updated successfully, but these errors were encountered:
As discussed in PR (#1638) we can move to opener, which opens in background by default without waiting for the child process to finish.
opener
I just took another look in open and saw that there is also that_in_background.
open
that_in_background
Using that_in_background we would need to take care of joining the thread handle.
I can create a new PR, any preference on staying with open or switching to opener?
Sorry, something went wrong.
I would probably lean towards using opener. That is what we use in Cargo, so I am more familiar with it from there.
Created new PR (#1656), switching to opener.
Successfully merging a pull request may close this issue.
In case the
watch
feature is enabled and we run one of the following commandslistening for file changes is blocked until the browser is closed.
Should we open the browser in a separate thread and start listening for changes immediately?
See PR (#1638) for example.
The text was updated successfully, but these errors were encountered: