GNU bug report logs - #76561
[PATCH] Promote desktop-dirname to a defcustom

Previous Next

Full log

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

From: João Guerra <joca.bt <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76561 <at> debbugs.gnu.org
Subject: Re: bug#76561: [PATCH] Promote desktop-dirname to a defcustom
Date: Tue, 25 Feb 2025 21:03:42 +0100

Hi Eli, I was just testing it out again and overriding desktop-path is
enough for the behaviour I was looking for. No need to manually run
desktop-save or anything (which I wanted to avoid on the first run).
I'm flabbergasted. I'm not sure why I was always overriding it. I've
also seen similar configurations doing the same (e.g. no-littering).

It seems as desktop-read sets desktop-dirname even if a file is not
actually read due to not existing.

Thanks!

On Tue, 25 Feb 2025 at 20:43, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: João Guerra <joca.bt <at> gmail.com>
> > Date: Tue, 25 Feb 2025 19:12:37 +0100
> > Cc: 76561 <at> debbugs.gnu.org
> >
> > Hello, the idea is to allow the user to customize where the desktop
> > file is saved by default. Currently, the user can only customize the
> > name for the file, its lock, and the directories where to search for
> > desktop files for loading.
>
> That's not true: if you invoke "M-x desktop-save", it will prompt you
> for the directory in which to save, and will record that directory in
> the desktop-dirname variable for future saves.  This is one way users
> have today to customize where the desktop is saved.
>
> > Note that desktop-dirname appears in the documentation of other
> > options, which can lead to the idea that it can be customized. For
> > example:
> >
> > ```
> > (defcustom desktop-save 'ask-if-new
> >   "Specifies whether the desktop should be saved when it is killed.
> > ...
> > The variables `desktop-dirname' and `desktop-base-file-name'
> > determine where the desktop is saved."
> > ```
>
> Yes, because various commands, like desktop-save, desktop-read,
> desktop-change-dir, and others, set the variable.
>
> > > If users customize desktop-dirname to some value, and desktop.el will be forced to use this value unconditionally (as it should do with user options), then this feature will be lost.
> >
> > Since the user can only have one desktop active at a time, it
> > shouldn't be problematic but I now understand that's not ideal. In
> > that case, what about introducing a new option that feeds the
> > variable? Unless there are already other alternatives.
>
> See above: there are already other alternatives.

Previous Next

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