[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: |
Naofumi Yasufuku |
Subject: |
bug#49507: 28.0.50; macOS: Symbol’s value as variable is void: lock-file-name-transforms |
Date: |
Sun, 11 Jul 2021 07:42:15 +0900 |
User-agent: |
mu4e 1.4.15; emacs 27.2 |
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Naofumi Yasufuku <naofumi@yasufuku.dev> writes:
>
>> Precondition:
>> - Repository revision: 9ce6541ac9710933beca7f9944087fe4849d5ae9
>> - macOS
>> - $ mv ~/.emacs.d/eln-cache ~/.emacs.d/eln-cache.old
>>
>> Emacs doesn't start due to the following error:
>> $ ./src/emacs -Q
>> Symbol’s value as variable is void: lock-file-name-transforms
>> $
>
> [...]
>
>> - return call1 (Qmake_lock_file_name, Fexpand_file_name (fn, Qnil));
>> + Lisp_Object func = intern ("make-lock-file-name");
>> + if (NILP (Fboundp (func)))
>> + return Qnil;
>> + return call1 (func, Fexpand_file_name (fn, Qnil));
>
> Well, that code was buggy (as Michael pointed out) -- Fboundp doesn't
> work on interned symbols, apparently?
>
> But in any case, make-lock-file-name and lock-file-name-transforms are
> defined in the same file ("files.el"), so what you're seeing here just
> shouldn't be possible -- it should complain about make-lock-file-name
> being undefined, not the variable.
>
I found that the following simple `lock-file-name-transforms' change
can also avoid this error:
----
lisp/files.el | 1 -
1 file changed, 1 deletion(-)
diff --git a/lisp/files.el b/lisp/files.el
index 0dfcab8f89..894a06e6e7 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -424,7 +424,6 @@ lock-file-name-transforms
:type '(repeat (list (regexp :tag "Regexp")
(string :tag "Replacement")
(boolean :tag "Uniquify")))
- :initialize 'custom-initialize-delay
:version "28.1")
(defvar auto-save--timer nil "Timer for `auto-save-visited-mode'.")
----
> So I think this points to there being something odd going on in your
> build tree. Are you sure you have no private modifications in the tree?
> Do you still see this issue from a freshly checked out tree?
I've tested with fresh build of new checked out under both macOS and
linux (Ubuntu 21.04). The result is same.
bug#49507: 28.0.50; macOS: Symbol’s value as variable is void: lock-file-name-transforms, Lars Ingebrigtsen, 2021/07/10
- bug#49507: 28.0.50; macOS: Symbol’s value as variable is void: lock-file-name-transforms,
Naofumi Yasufuku <=
- bug#49507: 28.0.50; macOS: Symbol’s value as variable is void: lock-file-name-transforms, Eli Zaretskii, 2021/07/11
- bug#49507: 28.0.50; macOS: Symbol’s value as variable is void: lock-file-name-transforms, Lars Ingebrigtsen, 2021/07/11
- bug#49507: 28.0.50; macOS: Symbol’s value as variable is void: lock-file-name-transforms, Eli Zaretskii, 2021/07/11
- bug#49507: 28.0.50; macOS: Symbol’s value as variable is void: lock-file-name-transforms, Stefan Monnier, 2021/07/11
- bug#49507: 28.0.50; macOS: Symbol’s value as variable is void: lock-file-name-transforms, Eli Zaretskii, 2021/07/11
- bug#49507: 28.0.50; macOS: Symbol’s value as variable is void: lock-file-name-transforms, Stefan Monnier, 2021/07/11
- bug#49507: 28.0.50; macOS: Symbol’s value as variable is void: lock-file-name-transforms, Lars Ingebrigtsen, 2021/07/12
bug#49507: 28.0.50; macOS: Symbol’s value as variable is void: lock-file-name-transforms, Stefan Monnier, 2021/07/11
bug#49507: 28.0.50; macOS: Symbol’s value as variable is void: lock-file-name-transforms, Lars Ingebrigtsen, 2021/07/16