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

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

[Campbell Barton]

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?

-- 
- Campbell

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

[Stefan Kangas]

Campbell Barton <ideasman42@gmail.com> writes:

> Is this a known problem or is it worth a fill bug report?

In general, it is better to just file a bug report than asking this
question.  If it is a known issue, we will merge your new report with
an old one.

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

[Lars Ingebrigtsen]

Campbell Barton <ideasman42@gmail.com> writes:

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

If you say

emacs -Q
M-: (require 'calc)

does that trigger the problem for you?

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

[Zhiwei Chen]

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

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

[Campbell Barton]

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