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

Previous Next

Package: emacs;

Reported by: João Guerra <joca.bt <at> gmail.com>

Date: Tue, 25 Feb 2025 17:48:01 UTC

Severity: normal

Tags: patch

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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




This bug report was last modified 80 days ago.

Previous Next


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