bug#17873: 24.4.50; `desktop-save'

[Drew Adams]

> > Just say that if the desktop information has not changed since it
> > was last saved then the file is not rewritten.
> 
> Is this how you propose to fix the docstring?
...
> +If AUTO-SAVE is non-nil, compare the current desktop information
> +to that in the desktop file, and if the desktop information has not
> +changed since it was last saved then the file is not rewritten."

Yes (assuming that is the behavior).  But it is slightly better to
stick with the active voice for both parts of the last sentence:

  ...compare... and if the desktop information has not changed since
     ^^^^^^^
  it was last saved then do not rewrite the file.
                         ^^^^^^^^^^^^^^

> > 2. I also have a question about the behavior: Why is writing the
> > file even when the content is unchanged the default behavior?  Why the
> > need to specify AUTO-SAVE instead of an optional SAVE-EVEN-IF-NO-CHANGE?
> > Is this just for backward compatibility?  (Before AUTO-SAVE was
> > introduced the behavior was to update the file even if the desktop
> > info was not changed.)
> 
> When the user executes `M-x desktop-save RET' explicitly, the desktop
> has to be saved unconditionally as expected by users, e.g. it will
> update the file timestamp, and do other usual things.

I see.  That makes sense, I guess.

But depending on what the "other usual things" are, I can see that
it might be good for this to be optional (e.g. dependent on a user
option).

IOW, does a user who asks to save a desktop (perhaps just to make
sure) necessarily care about the timestamp and those other usual
things?  I can see that a user might, but I can guess too that s?he
might not.  Perhaps the option for the case where the content has
not changed could have values `always', `never', and `ask-me'.
Just a thought.  I suppose the desktop file size might play a role
in a user's preference.

> The only missing thing that `desktop-save' doesn't do yet is creating
> a backup copy, but this is currently under discussion in bug#17351.

FWIW, I am not following that thread.  I trust that those
participating in it will DTRT.  But I certainly am in favor of a
user being able to opt for automatic backups of desktop files (or
to opt out).

Probably my only concern in this regard is this: If such a feature
is implemented then I hope that the backup copy for a given desktop
file is related somehow to the name of the file being backed up.
(This is the case for Emacs backup files in general, so I expect
there won't be a problem in this regard.)

I mention this because desktop.el still suffers from an ungainly
design wrt desktop files: it more or less assumes there is at most
one per directory.  Functions such as `desktop-save' and
`desktop-read' do not let you pass a file name (e.g. absolute)
for the file to be saved/read - they rely on the directory name.
To me, that's silly - an unnecessary design limitation (which I
have pointed out before, FWIW).

I use desktops in the form of desktop bookmarks, for instance,
and it is quite common for multiple such bookmarks to reference
desktop files located in the same directory.

It's OK.  I jump through a few minor hoops to get around the
single-file-per-directory design/expectation.  (I define save
and read functions that accept a file name, for instance.)
But I would not want desktops to become further cobbled by a
similar assumption wrt backup files.