[OS X TeX] Skim SKAutoReloadFileUpdate
Adam R. Maxwell
amaxwell at mac.com
Fri Dec 19 18:42:28 CET 2008
On Dec 18, 2008, at 2:13 PM, Enrico Franconi wrote:
> On 18 Dec 2008, at 17:09, Adam R. Maxwell wrote:
>> Depends on how clever you want to be :). The trivial way is to
>> test the exit value of the process and see if it's zero (success)
>> or anything else (failure). Practically, you probably wouldn't
>> like that, since TeX returns nonzero pretty frequently, even though
>> it created a usable PDF. You could count the number of error:
>> lines it spits out, but that might get hairy.
>> The easiest solution is probably a compromise: wait until all of
>> your tex/bibtex/index processes are done, then try to reload the
>> file. That eliminates the race condition, so you're left with
>> potentially trying to open a garbage file.
> And how this behaviour would be *in practice* better than a
> potential rare crash of Skim that by the way I (nor other users,
> apparently) never had in a continuous use of Skim?
If you don't wait, you have a race window for each run of pdftex, and
you'll be trying to load garbage at least some of the time. In spite
of the test for the trailer, the pdftex process runs separately from
Skim, so it can truncates the file and start writing again while it's
The way I have described is faster (avoids multiple reloads), and
allows at least some sanity checking if you test for return value or
grep for errors. It's rare that pdftex produces unreadable PDF files,
so if the process completes, you have a high probability of being able
to open the file.
> So, it seems to me that the auto feature is the best compromise to
> have a smooth workflow.
If you want to use a brute force reloading and hope that corrupted
data structures are dealt with correctly everywhere in Apple's
frameworks (they're not), go for it. Personally, I think it's a
foolish approach when the problem is easily avoided.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2415 bytes
Desc: not available
More information about the macostex-archives