Re: Error "load: Symbol’s value as variable is void: \213" since 261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137

[Campbell Barton <ideasman42@gmail.com>]

On Sun, Aug 7, 2022 at 1:50 AM Zhiwei Chen <condy0919@gmail.com> wrote:
>
> Campbell Barton <ideasman42@gmail.com> writes:
>
> > Hi ever since 261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137 I'm getting an
> > error starting emacs,
> > to be sure there isn't anything strange going on, this happens with a
> > clean build, ELN removed (with/without native compilation), and with a
> > freshly installed package directory.
> >
> > --- error output ---
> > Debugger entered--Lisp error: (void-variable ‹)
> >   eval-buffer(#<buffer  *load*-527550> nil
> > "/opt/emacs/share/emacs/29.0.50/lisp/calc/calc-loaddefs.el.gz" nil t)
> > ; Reading at buffer position 3
> >   load-with-code-conversion("/opt/emacs/share/emacs/29.0.50/lisp/calc/calc-load..."
> > "/opt/emacs/share/emacs/29.0.50/lisp/calc/calc-loaddefs.el.gz" nil t)
> >   load("calc-loaddefs.el" nil t)
> >   require(calc)
> > --- snip ---
> >
> > This error happens to be triggered by evil-mode but if I disable evil
> > mode it gets triggered by lsp-mode, so it doesn't seem specific to a
> > single package,
> > although `emacs -Q` works without problems.
> >
> > I bisected the error to:
> > http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137
> >
> > Is this a known problem or is it worth a fill bug report?
>
> I suspect you're the victim of `file-name-handler-alist' optimization
> [1]. Since it sets `file-name-handler-alist' to nil, it can't unpack
> *.el.gz on-the-fly and then eval it.
>
>     $ hexdump /usr/share/emacs/29.0.50/lisp/files.el.gz -C | head -n1
>     00000000  1f 8b 08 00 00 00 00 00  02 03 ec 5c ff 73 db 46  |...........\.s.F|
>
> The '\213' (0x8b) is the second byte of an el.gz file.
>
> [1]: https://github.com/doomemacs/doomemacs/blob/master/early-init.el#L31-L48
>
> --
> Zhiwei Chen

This was the problem, thanks!

Aside from avoiding setting `file-name-handler-alist` to nil entirely,
The error can be avoided by removing  `--without-compress-install`
when building emacs.

An alternative could also be to limit the alist to only use
compression handlers, e.g:
(setq file-name-handler-alist (list (rassoc 'jka-compr-handler
my-original-file-name-handler-alist)))
Although in my tests this loses the performance gains from setting it to nil.

Since this is a fairly common optimization it seems likely others may
run into it, so it may be good if the error message could be made less
cryptic somehow, although I'm not sure if that's reasonable.
-- 
- Campbell