Symbol's value as variable is void - after update system

[jackgris]

Description

After updating the emacs version to 29.1-4 (the latest stable version in my system Linux 6.1.44-1-MANJARO #1 SMP PREEMPT_DYNAMIC Wed Aug 9 09:02:26 UTC 2023 x86_64 GNU/Linux).

When emacs start I only get this message:

⛔ Error (use-package): window-purpose/:config: Symbol’s value as variable is void: fun-name
⛔ Error (use-package): winum/:catch: Symbol’s value as variable is void: fun-name
⛔ Error (use-package): ws-butler/:catch: Symbol’s value as variable is void: fun-name
⛔ Error (use-package): xterm-color/:catch: Symbol’s value as variable is void: fun-name
⛔ Warning (initialization): An error occurred while loading ‘/home/username/.emacs.d/init.el’:

Symbol's value as variable is void: fun-name

Reproduction guide 🪲

• Update Emacs to the last stable version
• pull the last changes from the Spacemacs repository
• Start Emacs
• I get the error in the above description

Observations: 👀 💔

I tried with a new fresh installation (removing .emacs.d folder and .spacemacs file) but still the issue remains there.

If I try to update the packages I get this message:

⛔ Warning (spacemacs):
Error while contacting melpa repository!

I also tried this: How to fix Symbol's value as variable is void errors on startup? but didn't work.

And when I run emacs with the flag --debug-init I didn't get any error in the terminal.

[stkain]

Hi,
the cause seems different from just updating to 29.1.
I was on 29.1 for a week without problems.

Today when I started the elpa/melpa package update
this lead to an abort. and from now on spacemacs startup fails with
the same message as by the original reporter.
Symbol's value as variable is void: fun-name
I then did a git clean -fdX in the .emacs for a fresh install.
This leads to the same problem.

I will try to make an initial install without custom .spacemacs.
Maybe this still works.

My guess is that some elpa package has a major bug "bricking" spacemacs

Bye,

[stkain]

Ok, initial "installation" with default .spacemacs works.

as --debug-init does not make a difference (does not stop in the debugger) I will
enable my layers one by one and see which one causes the problem

[mirkov]

I have just installed Emacs 28.2 on a new company Windows (using MSYS2) and I am starting up Spacemacs.

I have the same problem. --debug-init is not helping either.

In the *Messages* buffer, the first occurence of the error is as follows (transcribed from the Emacs window):

An error occurred while post-configuring evil-matchit in layer html (error: (void-variable fun-name))

I have Emacs 28.2 & (a several months old devel version of) Spacemacs running on another Windows machine, and fun-name does not exist on it either as a function or variable.

Other files/commands that issue the error while loading or in action are:

• post-command-hook evil-mode-check-buffers
• while loading spacemacs-defaults/keybindings.el
• running timer global-git-gutter-mode
• during redisplay spaceline-ml-main
• post-command-hook evil-activate-visual-state

[dankessler]

Ok, initial "installation" with default .spacemacs works.

as --debug-init does not make a difference (does not stop in the debugger) I will enable my layers one by one and see which one causes the problem

Installation with default .spacemacs "works" (which I forced by just deleting my customized .spacemacs file), but if I exit and relaunch spacemacs, I'm right back in these errors. I even tried removing all layers and user-added packages, and I still get the error, so I fear it's something very core.

Of course, I too tried cleaning my repo of all local files which borked my ability to do a package rollback. Although spacemacs was too broken to do it, I suppose I could've done it manually, but not anymore :(

I hope that if this breaks things for so many people, it'll get noticed and fixed quickly

[dankessler]

Running rip-grep fun-name -uuu turns up fun-name in evil-common.el.

I suspect this is where the bug was introduced: emacs-evil/evil@0cbd61f#diff-47302cddd5e39bfe2c8dcd1b006b8a2c683f070472d9bb138d20a243a3d71aa1L61-L62

[dankessler]

W00t! Crudely reverting that edit by manually editing my local evil-common.el file so that lines 60-61 read

        ((fun-name `',(make-symbol
                     (or name (format "evil-delay-in-%s" hook-sym))))

fixes the issue for me.

For anyone coming to this and wanting to quickly fix it, the file I edited was at
.../elpa/29.1/develop/evil-20230812.92937/evil-common.el, although your path may vary.

[dankessler]

TLDR: This is a bug in evil and has been (hastily) reported upstream : emacs-evil/evil#1820

If you have updated your packages and received the bugged version of evil, you can fix it by editing evil-common.el so that lines 60-61 read

        ((fun-name `',(make-symbol
                     (or name (format "evil-delay-in-%s" hook-sym))))

and it's likely prudent to also delete the corresponding *.elc file (h/t @mirkov )

[mirkov]

Just to add some details to dankessler's recipe to fix the error :

I found two identical instances of evil-common.el in my ~/.emacs.d/ directory. I edited the one in the .emacs.d/elpa/28.2/develop/evil-20230812.92937/ directory, and then deleted its *.elc file.

Spacemacs came up.

[jackgris]

Thanks @dankessler, that works!! and I see that they responded to your issue in the evil repository.
They fixed it, so I'll close the issue.

[dankessler]

Great! While this now seems fixed upstream, anyone whose spacemacs is currently bricked may need to first use my suggested fix in order to get spacemacs working well enough to update packages, at which point they should be good to go.

[mirkov]

Is another option to delete that package manually from emacs.d? That would force Spacemacs do download the package, and thereby fetch the new version.
I did not test that yet.

[dankessler]

Is another option to delete that package manually from emacs.d? That would force Spacemacs do download the package, and thereby fetch the new version. I did not test that yet.

That would probably also work

[mirkov]

I did:

1. remove all elpa packages from ~/.emacs.d. I found them in ~/.emacs.d/.cache/quelpa/build and ~/.emacs.d/elpa/28.2/develop
2. restart Spacemacs

Spacemacs picked up the just released 20230813.1704 evil package and resumed normally.

Thank you for identifying the bug and alerting maintainers.