[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