bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#60600: 30.0.50; [PATCH] Document manual desktop restore


From: Eli Zaretskii
Subject: bug#60600: 30.0.50; [PATCH] Document manual desktop restore
Date: Fri, 06 Jan 2023 15:15:46 +0200

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 60600@debbugs.gnu.org
> Date: Fri, 06 Jan 2023 13:26:27 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The new text seems to imply that using "M-x desktop-save" necessarily
> > means restoring must also be manual.  But this is only true if
> > desktop-save-mode was not enabled.  I have the mode enabled, and I
> > still sometimes save the desktop manually, whenever I make some
> > significant change to the session, to make sure the new arrangement is
> > saved and not lost due to some catastrophe.
> >
> > So the change needs to be reworded not to imply the mistaken
> > interpretation that saving manually requires restoring manually.
> 
> Ok but OTOH, when you are not using desktop-save-mode (as I do) after
> the manual save explanation you are left wondering « how could I restore
> it when I need to? » and then the text goes on about setting up
> desktop-save-mode.  That's why I placed this sentence here.  Maybe it
> need some rewording but I don't know how I could do it.

I find the organization of the text in that section not very logical
in general.  It begins by describing not-very-important optional
features.  It should instead start by describing desktop-save-mode,
since this is the recommended use of this facility, and leave the
manual saving/restoring for later (explaining why one would want to do
it manually).  When it describes desktop-save-mode, it should mention
that saving happens also from time to time, not just upon exit,
something that for some reason is described much later in the section.
And the order of describing the various optional features seems to
lack any logic, which at least should be to describe the more
significant/important options (such as desktop-load-locked-desktop,
for example) first.

Feel free to rewrite the section along the above lines; if not, I will
do that soon, hopefully also taking care of the issue you raise.

> And BTW, shouldn't desktop-revert be the user facing interface here?

What do you mean?  desktop-revert is described in that section (again,
without any hint about when it could be useful).





reply via email to

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