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

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

bug#49507: 28.0.50; macOS: Symbol’s value as variable is void: lock-file


From: Eli Zaretskii
Subject: bug#49507: 28.0.50; macOS: Symbol’s value as variable is void: lock-file-name-transforms
Date: Sun, 11 Jul 2021 17:50:45 +0300

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  49507@debbugs.gnu.org,
>   naofumi@yasufuku.dev
> Date: Sun, 11 Jul 2021 10:27:11 -0400
> 
> > However, given this incident, I'm worried that others could trip on
> > this subtlety.  So I wonder whether we should describe it in the ELisp
> > manual.
> 
> What is "it"?  `custom-initialize-delay` is described in
> `lispref/custom.texi` so are you suggesting that we don't describe
> it there?

No, I'm saying that we should recommend its use only with variables
that are defined in C, which makes sure they are defined by the time
the startup code runs.

> > I think we should generally advise against using this tag for
> > defcustom's that might affect the startup code itself.
> 
> We should generally advise against using this initialization function
> at all.  Obviously it has its uses, but it's finicky.
> 
> > For 100% safety, one should probably use it only with variables
> > defined in C.  Stefan, do you agree?
> 
> I don't see why being defined in C would be relevant, no.

Because those are always defined when the startup code runs.  By
contrast, if you define them in some preloaded Lisp file, the
defcustom form could run before the preloaded Lisp is restored from
the pdumper file.

Maybe I'm confused, but in that case can you describe why the error
happens for lock-file-name-transforms when the startup code needs to
lock a file early on?





reply via email to

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