GNU bug report logs - #17873
24.4.50; `desktop-save'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17873 in the body.
You can then email your comments to 17873 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; `desktop-save'
Date: Sun, 29 Jun 2014 09:47:07 -0700 (PDT)

1. The doc string says:

 If AUTO-SAVE is non-nil, compare the saved contents to the one last saved,
 and don't save the buffer if they are the same.

Saved contents of what?  One what last saved?  Saved contents cannot be
compared to "the one" anything.

I think you mean "compare the current desktop information to that in the
desktop file."  If you are avoiding saving (because the contents are the
same) then you cannot speak of comparing the "saved contents" - the
contents have not yet been saved.

And what buffer?  This is about saving a desktop in a desktop-file.
There is no notion of a buffer here - at the user level.  The code puts
the desktop info into a buffer (which then might get saved), but that is
implementation-level.

What `desktop-save' does needs to be described at a user level (what,
not how, unless that is important to users).  Just say that if the
desktop information has not changed since it was last saved then the
file is not rewritten.

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.)

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-06-17 on ODIEONE
Bzr revision: 117359 monnier <at> iro.umontreal.ca-20140617193358-2t1nl1te9gc2mqrx
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
 LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''

Message #8 received at 17873 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 17873 <at> debbugs.gnu.org
Subject: Re: bug#17873: 24.4.50; `desktop-save'
Date: Mon, 30 Jun 2014 02:59:20 +0300

> 1. The doc string says:
>
>  If AUTO-SAVE is non-nil, compare the saved contents to the one last saved,
>  and don't save the buffer if they are the same.
>
> Saved contents of what?  One what last saved?  Saved contents cannot be
> compared to "the one" anything.
>
> I think you mean "compare the current desktop information to that in the
> desktop file."  If you are avoiding saving (because the contents are the
> same) then you cannot speak of comparing the "saved contents" - the
> contents have not yet been saved.
>
> And what buffer?  This is about saving a desktop in a desktop-file.
> There is no notion of a buffer here - at the user level.  The code puts
> the desktop info into a buffer (which then might get saved), but that is
> implementation-level.
>
> What `desktop-save' does needs to be described at a user level (what,
> not how, unless that is important to users).  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?

=== modified file 'lisp/desktop.el'
--- lisp/desktop.el	2014-06-24 23:23:41 +0000
+++ lisp/desktop.el	2014-06-29 23:58:41 +0000
@@ -946,8 +946,9 @@ (defun desktop-save (dirname &optional r
   "Save the desktop in a desktop file.
 Parameter DIRNAME specifies where to save the desktop file.
 Optional parameter RELEASE says whether we're done with this desktop.
-If AUTO-SAVE is non-nil, compare the saved contents to the one last saved,
-and don't save the buffer if they are the same."
+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."
   (interactive (list
                 ;; Or should we just use (car desktop-path)?
                 (let ((default (if (member "." desktop-path)

> 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.

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.

Message #11 received at 17873 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 17873 <at> debbugs.gnu.org
Subject: RE: bug#17873: 24.4.50; `desktop-save'
Date: Sun, 29 Jun 2014 19:10:24 -0700 (PDT)

> > 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.

Message #16 received at 17873-done <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 17873-done <at> debbugs.gnu.org
Subject: Re: bug#17873: 24.4.50; `desktop-save'
Date: Thu, 03 Jul 2014 02:47:06 +0300

Version: 24.4

> 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.
>                          ^^^^^^^^^^^^^^

Thanks, fixed.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.