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: 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.





reply via email to

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