[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  
being loaded.

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.

-- 
Adam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2415 bytes
Desc: not available
URL: <http://tug.org/pipermail/macostex-archives/attachments/20081219/cff652e9/attachment.bin>


More information about the macostex-archives mailing list