Skim version: 1.7.8
macOS version: 15.2 (Apple M2)
Bug description:
I have Skim's Sync setting configured to Check for file changes, Reload automatically and use the Aquamacs preset. Using autex within Aquamacs (v3.6) to re-display a pdf file causes Skim to throw up an "Unable to load file" message box with an "OK" button. On clicking the OK button, the file does in fact (re)loads. So this bug (if it is one) is an irritation rather than a deal breaker. Worse still, the message box does not appear every time Aquamacs calls Skim, just sometimes.
Does the Aquamacs command calls Skim to reload the file (i.e. calls displayline with the -r option)? In that case you should not also configure Skim to reload the file automatically, because than Skim is instructed to reload the file twice at the same time, giving problems. See also the comment in the Sync preferences.
I am not sure how to find out exactly what the Aquamacs command is sending to Skim (sorry!), but whatever it is, it has not changed recently. The Aquamacs-Skim interaction worked fine for me with Skim settings as described until recent Skim versions.
Unchecking "Reload automatically" in the Skim Sync settings does not solve the problem for me --the message box still pops up. Unchecking "Check for file changes" does of course solve the problem, but at the expense of having to manually revert the displayed pdf, negating the usefulness of the Aquamacs-Skim interaction.
There certainly has not changed anything on our side. So I wonder what has changed for you. Perhaps something else changed in Aquamacs?
But the fact that unchecking "Check for file changes" does lead to the PDF not being reloaded seems to indicate that the command from Aquamacs does not reload. So perhaps it should.
I find it very strange that you get the error message, and it still reloads the file. With this error message there should not be a new file to be reloaded found. All I can think of is that somehow Aquamacs updates the file twice in short sequence, and replaces it again while Skim is just trying to reload the file (and therefore fails).
And when did this start changing? It cannot be because of Skim, as that updates the same way it always did.
OK it seems from what you say that this is an Aquamacs problem, not a Skim one . I will investigate my Aquamacs set up. I think you can close this ticket. Thanks for your super speedy responses.
I am using a simple vim+pdflatex setup, no fancy integration. Everytime I compile the file, now I am getting this annoying message that requires clicking "OK". My OS is Tahoe 26.3. Skim version 1.7.13. I am not sure when the problem has started exactly. Perhaps something has changed at the OS side? Thanks!
I couldn't tell. The certificate for Skim is still the same (it will probably change in the next release). Perhaps it is due to an OS change. It may be that you have to give Skim, the calling app, or some automatization process authorization in your system preferences. In particular when the file is in (a subdirectory of) the Documents or Desktop.
Thanks for your quick reply. In my case, the working directory is not located under Documents or Desktop, and skim has clearly read access. I think what is happenning is that skim is "not patient" : it tries to read the file while the file is still in a corrupt state (due to recompilation of the pdf), gives a warning prematurely, but then just after a fraction of a section, it loads the fıle correctly. If the warning could wait a bit more or close automatically after a correc re-load, the problem would be solved.
Skim does wait. But how long isz long enough? Skim still has to read the file precisely in order to figure out whether the file was fully written. There is no way around that, as we simply cannot know. That is just one of the problems of having automatic reload (and why we actually did not want to include that anyway). It is something you use at your own risk, that';s what we have always been saying. Pushing a file reload from the process running tex is much more reliable, and really the only way to do it reliably.
I fully understand. I guess there is no way to alter skim's patience so that it doesn't re-load until (lets say) "2" seconds after a change?
As a quick solution, I ended up adding a pdf-copy step and opening the copy of the file instead, which solves the problem in practice (in a non-ideal way).