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

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

bug#29988: 27.0.50; completing-read: Symbol’s function definition is voi


From: Noam Postavsky
Subject: bug#29988: 27.0.50; completing-read: Symbol’s function definition is void: internal-make-closure
Date: Fri, 05 Jan 2018 07:57:39 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux)

Robert Cochran <robert+Emacs@cochranmail.com> writes:

> Starting from `emacs -Q` on the lastest Git master branch revision
> (1cc7bc0f6 "Improve backward compatibility in tramp-archive" at time of
> writing):
>
> 1) C-h v RET
> 2) Get error in minibuffer, instead of prompt to specify variable.
>
> A bisect appears to point to ce4865819 ("Fix command repetition with
> lexical-binding (Bug#29334)") to be the culprit. I'm afraid I'm not much
> help in coming up with a fix though.

I thought byte-compile-lambda received the source form, but it looks
like it actually gets some kind of semi-compiled thing (which happens to
be valid lisp for simple or non-lexical code).  Getting the original
source form to that function looks to be pretty awkward; maybe the best
option is to revert the change and pursue the alternate methods
suggested by Stefan in Bug#29334.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29334#34

> At least for me, it took a very deep clean ('git clean -dXf' is what I
> used) for different checkouts to actually affect the result; doing a
> make distclean and *.elc removal on a known good build did not fix the
> error, only by doing the above Git command did I get any changes between
> checkouts.

Hmm, I would think removing elc, emacs, and emacs-bootstrap executables
should be enough.





reply via email to

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