[Openmcl-devel] One last (I hope) Cocoa question

Gary Byers gb at clozure.com
Mon Jan 25 11:28:32 PST 2010


The other question to ask is whether there's a way to make the RCS (and Emacs,
and ...) behave more like well-behaved Mac programs.  (There's a whole protocol
that "save" is supposed to go through to ensure that HFS aliases continue to
resolve; Cocoa applications seem to follow this protocol, but unix-level things
likely don't.)

You -might- be able to force NSDocument to re-synch its notion of what file
the document is associated with by doing something like:

(let* ((url (#/fileURL doc)))
   (revert-hemlock-buffer ...)
   (#/setFileURL: doc url))

I don't really know if that'd work, but I don't know why it wouldn't if it
doesn't.


On Mon, 25 Jan 2010, Ron Garret wrote:

> I think I have all the pieces working that I need to integrate a revision control system into Hemlock.  I can grab snapshots on every save by intercepting GUI::WRITE-HEMLOCK-BACKUP-FILE, and I can rollback by using the underlying RCS to rollback the file and then invoking hemlock-ext:revert-hemlock-buffer.  All that works, but there is a hitch: once the RCS has swapped out the underlying file (so that it now has a different inode), Cocoa won't let you save it any more, except by doing a SAVE-AS, which is annoying.  I can work around this by closing the editor window and then re-opening a fresh one on the (now new) file, but that seems like a Horrible Hack.  Does anyone know of a way to convince an NSDocument to reconnect itself to a file with the same name but a different inode?
>
> Thanks,
> rg
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>



More information about the Openmcl-devel mailing list