magit-section-maybe-cache-visibility: Symbol’s value as variable is void: alist-get

I'm getting

error in process sentinel: magit-section-maybe-cache-visibility: Symbol’s value as variable is void: alist-get

replacing

magit/lisp/magit-section.el

Line 1779 in 108ed15

(setf (compat-call alist-get

with compat-alist-get fixes the issue for me.

compat should have been updated when you updates magit. For some reason it wasn't, so you have to do it explicitly.

Also see #4836.

@tarsius Do you have any idea why that happens? We are explicit about the version requirements here, so why is Magit compiled with the old Compat version? Doesn't package.el ensure that Compat is updated before Magit in this case? Could it be that Magit on MELPA has been available earlier than the new Compat version on ELPA, which affects these users who updated in this time window? But then package.el should have refused to update Magit given the unsatisfied Compat dependency.

Last I checked package.el did not reload packages after updating them.

I am guessing that compat was already loaded but magit was not, when they both got updated. Then the user tried to use magit, which did not load the new compat because an old version was already loaded, and so compat-call is missing, resulting in this error.

So simply restarting Emacs should be enough in this case.

[Edit: That might not be enough. Also try recompiling magit and magit-section with the new compat already loaded. A safe way to do that is to remove all these packages, restart emacs and then reinstall. You could also use M-x byte-force-recompile (see below).]

Okay, thanks! This seems to be a rather harmless issue then. But to be clear, the compilation itself is not affected - package.el should make sure that the updated version of Compat was used to compile Magit?

But to be clear, the compilation itself is not affected - package.el should make sure that the updated version of Compat was used to compile Magit?

Unfortunately no. At least last I checked, package.el did not use an external emacs process to do the compilation, so whatever is currently loaded is used not only for the continued user session, but also the compilation.

In this case this should not matter because the macro was renamed in 4a799f5. Without this, the switch from a4db152 to cadcc74 would result in a franken compilation of all packages that depend on cadcc74 but were compiled while a4db152 was already loaded. Such issues can be very hard to debug, because the user is effectively using a version that "doesn't exist" in the source repository.

Because of this some very popular packages (I am aware of helm and magit) that constantly ran into these very frustrating "impossible" bugs resorted to monkey patching package.el to use an external emacs process for compilation, with the help of async-bytecomp.el. Eventually I stopped doing that because that also came with some heisenbugs and because backward incompatible changes to macros became much less frequent in my case. Helm still uses this, I believe. The position of emacs-devel was "this isn't really a problem in practice".

Okay thanks. I try to avoid byte code breaking changes in the future, except for the next release (current Compat development). I hope it is fine if you bump the Compat dependency for the next Compat release in Magit again? I will ping you in due time. After that I am convinced that no further breakage due to Compat should occur since from then on it will be addition only, existing functionality won't be changed or removed.

I hope it is fine if you bump the Compat dependency for the next Compat release in Magit again? I will ping you in due time.

Probably, and I will have a look when the time comes. 😁

After that I am convinced that no further breakage due to Compat should occur

And if any become necessary after all, then that is okay too. It's not you fault package.el is a bit stupid. This shouldn't be too hard to do properly. Borg, my own package manager, uses an external emacs instance to avoid franken compilations. (But it too does not reload packages in the current instance after an update, so it might still be necessary to restart emacs.)

Great, that's good to hear from you. I justed tested Magit against the current Compat master and this basic check seemed to work well (https://github.com/minad/magit/commit/3123f50450462a8755cc05dfe014cc50f67bd8e5).

I am still hitting this issue. I've got compat at 29.1.1.0 and I've restarted emacs.

Relevant lines from *Packages*.

  magit                          20230107.2134  dependency            A Git porcelain inside Emacs.
  compat                         29.1.1.0       dependency            Emacs Lisp Compatibility Library

Disregard my former comment. It appears I just needed to recompile any local .elc files in my .emacs.d directory.

Disregard my former comment. It appears I just needed to recompile any local .elc files in my .emacs.d directory.

No, thanks for hint. Could not resolve the issue until I found your advice.

Disregard my former comment. It appears I just needed to recompile any local .elc files in my .emacs.d directory.

This worked for me too. I'm still learning Emacs so I didn't know which command to run to do that, but what I did was M-x byte-force-recompile RET ~/.emacs.d/ RET and after restarting Emacs the error was gone.

Yups! Recompiling directory and restarting emacs works. \o/
Weird this needs to happen

This worked for me too. I'm still learning Emacs so I didn't know which command to run to do that, but what I did was M-x byte-force-recompile RET ~/.emacs.d/ RET and after restarting Emacs the error was gone.

I had this issue today. Thanks for the hint.

byte-force-recompile also worked for me. Just upgrading compat to 29.1.1.0 didn’t.

For straight users, I only was able to get rid of the issue after deleting compat and magit directories, and then restarting emacs.

❯ cd ~/.emacs.d/straight/repos
❯ rm -rf compat magit

byte-force-recompile worked for some commands like pulling, but I still get the error when unstaging changes. The changes do get unstaged, but the magit buffer does not update and still shows them as staged. Running magit-refresh fixes the buffer.

@d1egoaz Straight currently has some issues with the ELPA mirror synchronization. This may have caused some update issues. See radian-software/gnu-elpa-mirror#14 and radian-software/straight.el#1049.

I just had this issue and running byte-force-compile and restarting Emacs didn't fix it.

I just had this issue and running byte-force-compile and restarting Emacs didn't fix it.

Try removing all the magit-related packages (and all obsolete versions of them), then restart Emacs, then reinstall them.