emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A few questions about desktop.el


From: Stuart D. Herring
Subject: Re: A few questions about desktop.el
Date: Thu, 4 May 2006 09:17:30 -0700 (PDT)
User-agent: SquirrelMail/1.4.3a-11.EL3

>> Can you use a different file name for the "in use" marker?
>
> Wouldn't it be better to use Emacs standard file locking mechanism,
> i.e. after reading a desktop file to mark the desktop file's buffer
> as modified?  This ensures that trying to save the desktop in another
> Emacs session will raise a question about stealing/leaving the lock.

The desktop file is never in a buffer in the current scheme.  `load' is
called on the file, and then a new desktop is prepared in a file-less
buffer "*desktop*" which is then `write-region'ed to the desktop file. 
`write-region' supports locking (even for file-less buffers), but `load'
does not.  Obviously one could actually find the desktop file, lock it,
and then `eval-buffer' or so.  I just want it understood that it's not
compatible with the current architecture.

> Another simpler solution (without touching the desktop file's buffer) is
> to remember the desktop file's timestamp after reading it, and before
> saving it compare it with the old timestamp, and ask the question about
> whether to override it or not.

My patch does this, among other things.  The question arises, though, of
what to do when the desktop is being saved to a different file; the
desktop model does not involve "loading" and "saving" a desktop _file_
which is conceptually central and always-current, but rather "storing" and
"reloading" a desktop (session data), using the file only as a persistence
mechanism.

So the statement "your desktop file has been modified since you read it"
is somewhat wrongheaded, since during any Emacs session (or some
subsession using a particular desktop; there is a function
`desktop-change-dir') there is, conceptually, no "desktop file", just the
actual desktop.  My patch attempts to say meaningful things when loading
from an in-use A and saving to a modified B, but the heuristics might be
improvable.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]