bug#81499: 30.2; Truncation of custom settings when custom-safe-themes changes

Yes. There is a loss of all customizations of settings with names alphabetically greater than ‘custom-safe-themes‘.

-- 
Brad Howes
[email protected]

> On Aug 5, 2026, at 16:04, Sean Whitton <[email protected]> wrote:
> 
> Brad Howes [03/Aug 10:30am +02] wrote:
>>>> On Jul 31, 2026, at 12:23 PM, Sean Whitton <[email protected]> wrote:
>>> 
>>> [ please reply-all so your message reaches the bug tracker ]
>>> 
>>> Brad Howes [30/Jul  3:12pm +02] wrote:
>>>> Correct. However, as reported I have `custom-file` set and I have only
>>>> noticed the changes there. Unclear if same behavior exits when
>>>> `custom-file` is not set.
>>> 
>>> Thanks for confirming that.  It looks like we have a straightforward bug
>>> in the code for modifying/writing custom files.
>> 
>> Sean,
>> 
>> I did some additional investigation into this bug. I created a minimal reproducible case as follows:
>> 
>> Create an empty directory to serve as Emacs init directory — `mkdir ~/emacs.d.bug`
>> Create `elpa` subdirectory — `mkdir ~/emacs.d.bug/elpa`
>> Add `modus-themes-5.3.0` to `~/emacs.d.bug/elpa/` — `cp -r ~/.emacs.d/elpa/modus-themes-5.3.0 ~/emacs.d.bug/elpa/`
>> Create an `init.el` file in `~/emacs.d.bug` with the following contents:
>> 
>> ```
>> (setq custom-file (file-truename (locate-user-emacs-file "custom.el"))
>>      use-hook nil)
>> (message "custom-file: %s" custom-file)
>> 
>> (if use-hook
>>    (add-hook 'after-init-hook
>>              (lambda ()
>>             (when (file-exists-p custom-file)
>>               (message "after-init-hook loading custom-file '%s'" custom-file)
>>               (load custom-file 'noerror))))
>>  (message "init.el loading custom-file '%s'" custom-file)
>>  (load custom-file 'noerror))
>> ```
>> 
>> Create a `custom.el` file in `~/emacs.d.bug/` with the following contents:
>> 
>> ```
>> (custom-set-variables
>> ;; custom-set-variables was added by Custom.
>> ;; If you edit it by hand, you could mess it up, so be careful.
>> ;; Your init file should contain only one such instance.
>> ;; If there is more than one, they won't work right.
>> '(custom-enabled-themes '(modus-vivendi))
>> '(custom-safe-themes
>>   '(default))
>> '(dired-dwim-target t)
>> '(dired-isearch-filenames t))
>> 
>> (custom-set-faces
>> ;; custom-set-faces was added by Custom.
>> ;; If you edit it by hand, you could mess it up, so be careful.
>> ;; Your init file should contain only one such instance.
>> ;; If there is more than one, they won't work right.
>> '(show-paren-match ((t (:background "#0d0d0d" :foreground "spring green" :underline nil :weight ultra-bold)))))
>> ```
>> 
>> Start Emacs with the option `—init-directory ~/emacs.d.bug`
>> Emacs frame should appear with `Loading a theme can run Lisp code. Really load? (y or n)`
>> Answer with `y`
>> A new prompt should appear with `Treat this theme as safe in future sessions? (y or n)`
>> Answer with `y`
>> 
>> At this point, if `use-hook` is set to `t` in the `init.el` file, the `custom.el` file is truncated after the `custom-safe-themes` setting and the `custom-set-faces` will be empty.
>> If the `use-hook` variable is set to `nil`, no truncation takes place in the `custom.el` file and the `custom-safe-themes` value contains the hash of the theme.
>> 
>> So, it appears that changing performing the `load-file` from the `after-init-hook` is the source of the corruption.
> 
> Thanks.  Have you observed a case where only part of the
> custom-set-variables is deleted?  If not, then it seems like the problem
> is that Emacs is choosing to saving custom-file while the set of custom
> faces is empty, so it doesn't include those in the file.
> 
> --
> Sean Whitton