Re: A few questions about desktop.el

["Stuart D. Herring" <herring@lanl.gov>]

> I like the idea of using the standard locking mechanism, but I don't
> like to mark an unmodified buffer as modified.
>
> I think the desktop file should be locked as soon as we know it is going
> to be changed when Emacs exits, i.e. when desktop-save-mode is turned
> on. And if desktop-save-mode is turned off, the desktop file should be
> unlocked if its buffer is unmodified. So maybe lock-buffer should have
> an optional parameter LOCK-UNMODIFIED to make it usable in such cases (I
> take it this is an after-the-release discussion.)

So what happens if you turn desktop-save-mode off, another Emacs loads,
locks, overwrites, and unlocks the file, and then you turn
desktop-save-mode back on?  (The desktop file's buffer (if it is made to
have one) will always be unmodified unless the user explicitly finds it
and changes it; desktop does not use a buffer as some sort of "scratch
pad" whose state of modification would reflect the state of the abstract
desktop.)  Besides, someone could have a "standard desktop" that they load
frequently but save rarely, and so never have desktop-save-mode turned on.
 Then they might occasionally improve on or update the standard, and issue
an explicit (desktop-save) which would take place without the protections
of file locking.

In short, I don't think it's reasonable to "know it is going to be changed
when Emacs exits", because settings can change and it might even get
changed before Emacs exits (due to `desktop-save' or even
`desktop-change-dir').

>> [timestamp check suggestion]
>
> This is pleasingly simple, but then the question would be asked when
> Emacs is exited rather than when it is started. IMHO, the question
> should be asked as soon as the problem is detected, i.e. when the second
> Emacs is started (if desktop-save-mode is turned on).

My patch does this (as I mentioned in my reply to Juri); it also does what
you ask, although without the standard file-lock mechanism.  A separate
lock file is maintained which identifies (by PID) the owner of the desktop
file.  Then the second Emacs will see the file and complain about it
(regardless of the setting of `desktop-save-mode', for the reasons of
no-precognition mentioned above), although the user is allowed the option
of proceeding anyway (at which point it's up to the modification dates to
attempt a peaceful resolution later).

I encourage the testing of my patch to see if its behavior is close enough
to everyone's idea of safe, correct, vigilant, and intuitive.

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.