Opening the document in V2 on watch and new subcommands

[aarmn]

This is a feature request, but I would love to assist in its creation, or possibly even implement it entirely. However, it may seem bloat to some, so I prefer to seek feedback before writing the code. Do you think it's a good idea?

adding --opendoc and --opensrc to watch and new subcommands to open the document out and src in the based on program registered in mime db

e.g.: tectonic -X watch --opendoc # opens the document by looking in mime type for {out format} opener of system and open it by calling that on the file

So does it sounds like something to add or pass?

[Neved4]

Reminds me of something I use everyday: latexmk's -pvc option! I'd love if it came with a short flag (e. g. -l: live mode). I believe live compilation and preview is a great feature for authors workflow 🚀

[aarmn]

I think sth like -l --live-doc (for doc) and --live-src also can be a good combo. most of the times users like the live preview of their doc (and not source being opened for them in editor)

But the problem I find with live name is watch mode is also "live", but it does not open it, we want sth to indicate that it would open the doc

Also one hard edge case I'm thinking to is handling programs which do auto reload and don't, any idea for that? (e.g. browser do not auto reload their doc, nor many pdf readers, but, there are ways to make browser show content live and there are readers which do auto reload, so its better to e.g. if the pdf reader support it, do nothing and if it don't, kill it each time and reopen, tho maybe I'm over-complicating the matter)

[pkgw]

To check that I'm understanding correctly, are you imagining something similar to the --open option that tectonic build already has? That would definitely be a sensible addition, and could reuse the code that we already have there. Also, I think just --open would be a good name in that context. I am less sure about the new (or the just-added init) subcommand, since that seems like something that's going to be run much less frequently.

As for reloading, my Linux PDF readers will detect updates to their input files and automatically reload them as needed. I think it would be quite tricky for Tectonic to enable anything smarter if PDF readers on other operating systems don't have similar capabilities. Does anyone know whether the standard Mac and Windows tools will do that?

[aarmn]

Addition of --open flag to the watch sub-command sounds like a good idea as it is relatively easy to implement and makes sense in terms of functionality. It's not my initial plan but I think this is an even better idea.

And about testing common tools on win and linux, I can check some and share the results of live reloading in them.

update: I also tested tectonic -X watch -x "build --open" which is sort of the behavior I want to see, but it somehow hang to progress and kill on rebuild instead of reloading, which is a good idea, I think this is a bug/feature to complement the flag (if added), therefore supporting both auto reload and non auto-reload ones, to sum it up

if your pdf reader supports auto-reload: tectonic -X watch --open if your pdf reader doesn't support auto-reload: tectonic -X watch -x "build --open" (because it reopen reader on change, somehow) (by the harder way of tectonic -X watch -x "build --open")

[kpym]

On Windows the reader Sumatra reloads documents on change. This is one reason why it is popular in the latex community.

[Neved4]

Under macOS the reader Skim behaves in the same way.

[aarmn]

@pkgw If there is no document built, and build fail in watch command (with the --open flag), which behavior is better:

1. Opening nothing and waiting for one successful build, then opening
2. Ignoring the --open switch
3. Opening an empty document
4. Opening a document with tectonic error message (only when no built doc in output dir is available)
5. Opening a document with tectonic error message (every time build fails, even if the last working output is available)

[pkgw]

@aarmn I think your option 1 sounds the best. I can see the motivation for a behavior like 4 or 5, and that's how web server "watch" commands generally work, but we'd have to swap out the desired output file with the error document, and that seems like it could easily cause problems.

[aarmn]

Awesome! Then I probably need to learn more about the watch mechanism in use, I wish I can make it in less than a week.

[aarmn]

@mnrvwl @kpym I'm also planing to mention in documentation a hack for those people who use readers which do not support auto-reload, may you verify in your systems tectonic -X watch -x "build --open" would open a new window and close the last one on change? if not, what is the behavior you encounter? (it works on my system : NixOS+Plasma+Okular)

[aarmn]

@pkgw In case of behavior No.1, we need to rewrite the watch.rs code in something like notify instead of watchexec, is it alright? if not, do you have an idea for some sort of hack to make it possible in all platforms by running just one command? as far as I see, watchexec do not have a post change rust function call hook and just keep on executing a command, which make it fitting, for basic use-case (e.g.: the code already in use) but for more advance cases like handling first success in run, we gonna have some serious troubles. But I would dig watchexec a bit deeper before giving up on it

[pkgw]

@aarmn I think that it would be very good to have the "watch" implementation use something like notify. I think that the "watchexec" approach is definitely not as good from an engineering standpoint; it was just easier to implement. I would be happy to replace it with something better.

[Neved4]

@aarmn the behavior under macOS is the following:

1. tectonic -X watch -x "build --open" will open the Preview.app
2. Doing changes makes it reload on the fly, even if Preview.app generally doesn't have this ability —outside of watch, Preview.app reloads when the window is focused, selected with a click— so I assume it's being called again for every change

Is there any way to select or configure the viewer used by the watch command?

[aarmn]

@mnrvwl Thanks for your response!

Is there any way to select or configure the viewer used by the watch command?

There is currently no such feature available, and I guess it is not necessary. Using the system default is sufficient for most use cases. I read tectonic source and saw open crate is used for this part. To add custom app support, I would need to identify all the output types generated by Tectonic and then specify which app should be used for which format in a Tectonic-ish config style (e.g.: env variable maybe? or terminal flag? or maybe in tectonic.toml?). However, even after this, the <appname> <filename> command may not work as the program may open the file in a different way, and additional flags or adjustments may be required, such as ensuring the program is in the PATH (e.g. on Windows). I think I need to develop a full crate for that, and I'm alarmingly noob with rust for that! I would surely need help on that.

Although I generally support extra features, this task appears to be much more extensive than I had anticipated for my first day so I really want to just get it done.

If approved by @pkgw, after fixing this issue, we can brainstorm on that as well! For now, I guess the best way is to change macOS default .PDF handler app to your desirable app.

Also, If its possible for you, upload a short video of the behavior, I'm not on apple ecosystem therefore testing macOS target is close to impossible for me, and this feature is all about convenience across the platforms. I didn't quite get that the whole preview window refreshes, or it's the document which refreshes, I assume it should be the whole app, but please confirm.

[aarmn]

A brief update on the issue:

As I mentioned earlier, I am working on a tiny and reusable crate called "watchman" for Rust. It is designed to meet the specific needs of this project and is built on top of the notify watcher. However, it is not limited to it. As I mentioned before, any workaround of the current mechanism (with the chosen strategy in here) would harm the cross-platform nature of tectonic and bind it in some way that we would have to figure out later, probably on a random BSD machine or some other esoteric platform. In fact, it has already caused some harm with the env-var hack (appending the echo command) in the watch command. I believe this should be done with pure Rust or delegated to other crates.

My university has started, and I am a Rust newbie, so these two factors are slowing down the progress. I apologize for that, but progress is still happening. I have added some commits to my branch, and a bigger update is pending in the codespace of my account.

So, if anyone was waiting for it to happen sooner, I apologize for the delays. I am trying to put more effort into the update in the next two weeks, and hopefully, it will finally be completed and integrated!

[Jackaed]

Where did you get to with this? If this hasn't progressed, what's the best way of using this with VimTex?

[aarmn]

1. tectonic -X watch -x "build --open"

This is the best way yet,

I got some free time again to work on it, it's my fault to postpone this for near a year and it's not my proudest deadline handling.