When I work on a pdflatex document on multiple machines, synching with Dropbox, Skim won't automatically reload the document that has been modified by Dropbox. If I modify the .tex file and recompile (locally, not via Dropbox), Skim detects that, and tries to reload, but it just ends up with the old file. If, however, I close the PDF in Skim and reload it (from "Recent files") it works.
To reproduce:
Recompilation before Dropbox sync works file. I assume Dropbox messes with file IDs vs file names or something -- and maybe Skim could just be more naive about using the actual path? (Then again, it'd lose track if you moved a file, of course...) For example, vim automatically reloads my synched .tex files easily enough.
Maybe there could be an option/checkbox to use paths naively (rather than to use OS X "magic"), so that this would work? Or maybe it can be handled more elegantly, for all I know. (As far as I can tell, Preview doesn't manage this either, so it might be seen as a Dropbox problem, perhaps.)
We cannot do better than we currently do. The way dropbox updates the files makes it impossible to know which version of the file is actually the one we should be following, and it would be wrong to load the wrong one. Dropbox refuses to change that.
I see. But I believe Preview reloads modified Dropbox files correctly – do they use some information not available to non-Apple software? Or am I perhaps mistaken about this? IIRC, this was the behavior I experienced before I switched to Skim – and my motivation for using Skim was to avoid scrolling to the top when a file is rebuilt, etc. Would be nice to have a viewer that did both things correctly…
Would it be possible to have some optional functionality that's simply based on the path? I would even be happy if there was a “force reload” button that would use the normal reload behavior with the last-remembered path of the current path. That's essentially what I do manually – i.e., Close and then Open Recent -> [name of file]. That works, but has a couple of issues:
The second point is the main reason why I'd like to emulate the reload behavior that Skim has when a file changes locally. If it could even be done automatically, somehow (optionally/opt-in – perhaps even based on polling/checking the mtime of the given path, for all I care), that would be awesome.
So even if the ideal approach is somehow hindered by how Dropbox works, and even if we can't emulate whatever it is Preview does to solve this, it seems there are solutions that could be at least partially implemented by Skim – especially the ability to open a file with the previous scroll/zoom, but ideally also a quick “Reload current file based on path” command or the like. And perhaps, as the icing on top, doing it automatically.
Actually, I'd be happy if the “automatically” was approximated by “in response to a UNIX signal/AppleScript command“ – because then I could prod Skim from my makefile. (Not ideal, but still doable.)
Hey Magnus, here's an applescript you can call from your makefile:
call it with
osascript /path/to/ReloadSkim.scpt /path/to/document.pdf
This works for my needs: it retains syncTeX information and stays at the same scroll position. If you want to bring Skim to the foreground when you run it, add a
activate
to the line aftertell application
.Regards,
Tim