Resolves #29

[vqv]

This resolves #29 in a minimally intrusive way. Rather than trying to change the output filename using the -jobname argument to the latex engine, this PR modifies the file renaming logic and exit hook.

1. An existing PDF file will be renamed temporarily.
2. Upon successful compilation, the new PDF will be copied on top of the existing PDF (with the temporary name) and removed.
3. The PDF (existing or new) is renamed back.

These steps help external viewers detect changes to the PDF, because they will (hopefully) see that the PDF has been overwritten rather than just moved away.

[yihui]

I can see how this PR could fix the problem. My only concern is that file.copy() may be a little less efficient. Essentially, you changed file.remove(filep2) to these three steps: file.copy(filep, filep2, overwrite = TRUE); file.remove(filep); file.rename(filep2, filep).

There is a chance that I can completely get rid of the whole hack here (which existed only because of an edge case). Let me think more about it. Thanks!

[vqv]

Yes, this is a hack. The external PDF viewers that I've used on macOS (Preview, PDF Expert, and Skim) all hold on and follow a file pointer through renaming. A different approach is to build in a temporary directory and then copy on success. This also saves the trouble of deciding which files to clean up if there already existing temporary files.

I keep things in Dropbox, so I prefer to run the LaTeX compilation in a temporary folder that's not watched by Dropbox to avoid unnecessary syncing, but that can't be controlled with latexmk_emu().

[yihui]

I just removed my original hack. Please test the development version via

devtools::install_github('yihui/tinytex')

Thanks a lot!

[vqv]

That seems to fix it. Thanks! Now I've added a different feature request in #32 :-)