GNU bug report logs - #54399
27.2; Problems with (let ((custom-variable ...)) (autoload-function ...))

Previous Next

Package: emacs;

Reported by: Ignacio Casso <ignaciocasso <at> hotmail.com>

Date: Tue, 15 Mar 2022 15:53:02 UTC

Severity: normal

Tags: moreinfo

Found in version 27.2

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Ignacio Casso <ignaciocasso <at> hotmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, larsi <at> gnus.org, 54399 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#54399: 27.2; Problems with (let ((custom-variable ...))
 (autoload-function ...))
Date: Thu, 12 May 2022 10:41:56 +0200
> My point is that you seemed to be sating that you suggest a
> documentation change, but the changeset actually changes some code.
> So I'm not sure anymore what is this changeset about.  Perhaps I
> forgot what we were discussing at the beginning, since that was quite
> some time ago.  Can you remind?

Sure. It began as a bug report, but after you explained things to me,
all that was left were some mismatches between the docstrings of some
functions and their actual behavior: they use `default-toplevel-value'
and `set-default-toplevel-value' and their docstring said they use
`default-value' and `set-default'. And that is mainly what this patch
fixes, aside from another error in the docstring of
`default-boundp'.

The few non-documentation changes are just using the toplevel versions
of those functions in some places that were still missing, in functions
and places completely equivalent to those that are already using
them. This makes the use of those functions more consistent across
custom.el, and fixes in those new places the potential bug that those
functions were introduced to solve in the first place: calling
`defcustom' or customize functions inside a let-binding of the variable
in question (e.g., because a function inside the let body autoloads,
calling `defcustom')

A few further comments on each change:

> @@ -114,7 +114,7 @@ custom-initialize-changed
>                  symbol
>                  (eval (car (get symbol 'saved-value)))))
>        (t
> -       (set-default symbol (eval exp)))))))
> +       (set-default-toplevel-value symbol (eval exp)))))))
>  
>  (defvar custom-delayed-init-variables nil
>    "List of variables whose initialization is pending until startup.

The docstring of this function actually says that it behaves like
`custom-initialize-reset', which is already using
`set-default-toplevel-value'.


> @@ -717,7 +717,7 @@ custom-set-default
>    (if custom-local-buffer
>        (with-current-buffer custom-local-buffer
>  	(set variable value))
> -    (set-default variable value)))
> +    (set-default-toplevel-value variable value)))
>  
>  (defun custom-set-minor-mode (variable value)
>    ":set function for minor mode variables.

This would be the only setter function that does not use
`set-default-toplevel-value'.

> @@ -752,7 +752,7 @@ customize-mark-to-save
> @@ -779,7 +779,7 @@ customize-mark-as-set

These two I thought that I had remove them. Ignore them, they will not
be there in the next version of the patch

--Ignacio




This bug report was last modified 2 years and 342 days ago.

Previous Next


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