From: Adam R. M. <ama...@ma...> - 2007-06-05 13:37:47
|
On Jun 5, 2007, at 04:23, Christiaan Hofman wrote: > > > On 6/5/07, Christiaan Hofman <cmh...@gm...> wrote: > > > On 6/5/07, Adam R. Maxwell < ama...@ma...> wrote: > > On Monday, June 04, 2007, at 04:03PM, "Christiaan Hofman" <cmh...@gm... > > wrote: > >On 6/5/07, Adam R. Maxwell <ama...@ma... > wrote: > >> > >> > >> On Monday, June 04, 2007, at 03:43PM, "Christiaan Hofman" < > >> cmh...@gm...> wrote: > >> >When the file is deleted, the kqueue notification is broken. So > some > >> >atomic writing processes can give problems. How can this be fixed? > >> >Should there be a timier for this case? > >> > >> I'm not sure how many ways it can break, but I tried this: > >> > >> 1) run LaTeX on test.tex from TextMate, opens test.pdf in Skim > >> 2) in Terminal, rm test.pdf > >> 3) switch back to Skim; proxy icon for test.pdf is now gone, but > the > >> window is still there > >> 4) switch to TextMate, run LaTeX again, and the window for the > deleted > >> test.pdf comes to the foreground > >> > >> I'm not sure how to handle that case. The kqueue notification is > removed > >> now when the file is deleted or renamed, but it seems like the > "open POSIX > >> file" in displayline isn't handled correctly by > NSDocumentController, since > >> (IMO) it should be opening the newly created test.pdf file. Just > renaming > >> test.pdf to test2.pdf and then re-running latex works as I > expected, > >> though. > >> > >> Adam > > > > > >Opening a file shouldn't do anything if the file is already open, > even if > >the file has been updated. That's just normal opening procedure of > >documents. So I do think this behavior is basically correct. Also > because > >the script doesn't know about updates. > > That doesn't seem like expected behavior to me. If I delete a file > and then switch to Skim, the window no longer has a proxy icon, so > presumably no longer has a path on disk; if you hit cmd-s, it says > the location can't be determined. > > If I recreate a file on disk at the same path and then tell the app > to open it using the full path, I expect it to open the new file, > not switch to the window for a file that it just told me no longer > exists. Preview does the same thing, but it seems broken. > > Generally it is. Remember, Skim is a viewer, so it views what you > have loaded. This is the way open document works. Also if you open a > document e.g. by double-clicking. It does not change to a changed > file. So it is standard NSDocument behavior. > > Sorry, I mixed up some the different situations here. > > Deleting the file on disk indeed makes NSDocument lose its > connection to any file. So I guess we should also not try to watch > it for updates in this case, and remove it from the kqueue. It should be removed from the kqueue at that point. I didn't have time yesterday to mess with it any more, though, and I wasn't sure about save-as and save-to behavior. > Moving the file on disk /is/ noticed by NSDocument, though with a > delay (e.g. when you select the window). So I think we should try to > watch the moved file. I'm not sure how, perhaps we could do that in - > setFileURL, because that is called when the document notices the > change on disk. Ah, I don't think I tried that. I tried re-adding it after a delay in the move/rename handler, but that only worked if I clicked on the document first. I do agree that it should be watched automatically (although clicking Auto again isn't too painful). If this kqueue business is too much hassle, I won't argue against reverting to a timer, either. > Overwriting a file on disk is not noticed by NSDocument. By default > we should also not do that. The AS open command (or any file open > command) should not reload the file when it is already open and the > file on disk has changed. It can lead to data loss! Reloading the > (changed) file from disk is the responsibility of our file update > checking mechanism, and only that. Definitely! That's the autoReload BOOL ivar, right? I actually have to write this week, so I'll be testing BibDesk and Skim. -- Adam |