Dmitry Alexandrov <321942@gmail.com> wrote:
> Moreover:
>
> $ emacs -Q
> <f1> f emacs-lisp-mode RET
>
> Debugger entered--Lisp error: (wrong-type-argument stringp (require . elec-pair))
>   file-name-nondirectory((require . elec-pair))
>   file-name-sans-extension((require . elec-pair))
>   help-fns--autoloaded-p(emacs-lisp-mode "/var/share/pub/src/emacs.~21eef9fa7f~/lisp/progmod...")
>   help-fns-function-description-header(emacs-lisp-mode)
>   describe-function-1(emacs-lisp-mode)
>   describe-function(emacs-lisp-mode)
>   funcall-interactively(describe-function emacs-lisp-mode)
>   call-interactively(describe-function nil nil)
>   command-execute(describe-function)
>
> So something forgot to put there even nil, but started the list right with ENTRIES.

Okay, the cited part is only relevant when emacs(1) is run by symlink to the built yet not installed sources, i. e.:

$ ln -s src/emacs ~/.local/bin/

The easier noticeable comparative effect of that are several screens of output about loading basic libraries produced by emacs(1); like these:

$ emacs -Q
Loading loadup.el (source)...
dump mode: nil
Using load-path (/var/pub/src/emacs.~21eef9fa7f~/lisp /var/pub/src/emacs.~21eef9fa7f~/lisp/emacs-lisp /var/pub/src/emacs.~21eef9fa7f~/lisp/progmodes /var/pub/src/emacs.~21eef9fa7f~/lisp/language /var/pub/src/emacs.~21eef9fa7f~/lisp/international /var/pub/src/emacs.~21eef9fa7f~/lisp/textmodes /var/pub/src/emacs.~21eef9fa7f~/lisp/vc)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/byte-run...done
Loading emacs-lisp/backquote...
Loading emacs-lisp/backquote...done
Loading subr...
Loading subr...done
‹...›

Is not that going to be a supported configuration anymore (it has been working perfectly for a long time)?  That would be a pity, as it’s hardly expectable for a normal UNIX program to treat symlinks as an obstacle.