Closed bcc32 closed 3 years ago
Somewhat annoyingly, it is not possible to rollback packages through Spacemacs because Spacemacs fails to init. If this happens to you, the following workaround may help (this is just the rollback procedure, but done manually):
~/.emacs.d/elpa/$version/develop/
which-key
before 2021-06-21 in ~/.emacs.d/.cache/.rollback/$version/develop/$date/
and copy it into the directory in the previous step.Looks like an upstream bug.
From the debug traceback you can see that we haven't directly called any function that is changed in this commit.
So this looks like an internal error of which-key.
I am having the same issue and got the same kind of message.
Error (use-package): auto-yasnippet/:init: Key sequence i S c starts with non-prefix key i S
Error (use-package): emr/:config: Key sequence r d l starts with non-prefix key r d
Error (use-package): github-clone/:init: Key sequence g h c c starts with non-prefix key g h c
Error (use-package): github-search/:init: Key sequence g h c / starts with non-prefix key g h c
Error (use-package): js-doc/:init: Key sequence r d b starts with non-prefix key r d
Error (use-package): js2-refactor/:init: Key sequence x m j starts with non-prefix key x m
Error (use-package): rainbow-identifiers/:init: Key sequence C i s starts with non-prefix key C i
Warning (initialization): An error occurred while loading ‘/home/xxx/.emacs.d/init.el’:
error: Key sequence K r s starts with non-prefix key K r
I just downloaded latest which-key from here and replaced which-key.el
in elpa directory.
Looks it's working. The problem was which-key.
Thank you @bcc32
I grabbed this one: https://raw.githubusercontent.com/justbur/emacs-which-key/v3.5.2/which-key.el
@justbur sorry for tagging you, should I file an issue upstream?
@robbyoconnor if you can isolate the issue, yes.
@justbur Sorry for maybe not relevant, but after update to latest which-key(commit 28f386cc4af8c0fe21269bb587a5bb229ba3834e version: 20210622.334) general cannot work with which-key, Is there any breaking change? before:
after:
@tshu-w I use general and it's working fine for me. There might be an issue somewhere in how general defines replacements. I would need more information to determine what the issue is though.
@tshu-w I use general and it's working fine for me. There might be an issue somewhere in how general defines replacements. I would need more information to determine what the issue is though.
OK, I will create an issue tomorrow.
now 4c27fc0c565cdda58270dae4024ad03a0017de43 works.
4c27fc0c565cdda58270dae4024ad03a0017de43 doesn't work for me. I had to roll back to an earlier version as described above.
It's caused by these lines on startup: https://github.com/syl20bnr/spacemacs/blob/443311c8f1d7c6ebbe1d10be576a4edc47e03a5a/layers/%2Bspacemacs/spacemacs-defaults/funcs.el#L136-L142
And when the git
layer is enabled and a magit buffer is opened,
then a warnings buffer opens with the message:
Error (use-package): magit/:config: replacement is neither a cons cell or a string
It's caused by these lines: https://github.com/syl20bnr/spacemacs/blob/443311c8f1d7c6ebbe1d10be576a4edc47e03a5a/layers/%2Bsource-control/git/packages.el#L273-L279
Source: This was found by logging the which-key-add-keymap-based-replacements
parameters in which-key.el
(message "start of WHICH-KEY-ADD-KEYMAP-BASED-REPLACEMENTS")
;; (message "keymap: %s" keymap)
(message "key: %s" key)
(message "replacement: %s" replacement)
(message "more: %s" more)
which showed:
key: <normal-state> g r
replacement: nil
more: (<visual-state> g r nil)
before the error:
user-error: replacement is neither a cons cell or a string
according to the upstream issue, this is an issue with spacemacs' usage of that function
The previous fix doesn't seem to be needed anymore: Fix which-key entries: gr and gs in dired and magit https://github.com/syl20bnr/spacemacs/commit/ec57b21a924d88fa0f7e1d747f091c349cca0170
The expected which-key entries appear when the fix is reverted.
A PR has been opened with a possible fix by reverting the previous fix: Revert "Fix which-key entries: gr and gs in dired and magit" https://github.com/syl20bnr/spacemacs/pull/14869
The PR has been merged.
that took care of the issue for me, I think this issue can be closed. Thanks for the work!
@bcc32
Please verify if the bug is fixed.
Updating Spacemacs and then packages seems to have worked for me. I see no error messages at startup. Thanks all
Description :octocat:
Errors at init after updating which-key past a recent commit, https://github.com/justbur/emacs-which-key/commit/a55b90844c837e157c289ad4b10f5f2e3a4d53ff
I don't know whether this is a bug in which-key or whether Spacemacs is using a private interface that changed, so I reported it here. Happy to open an issue in which-key instead if it turns out the change there was broken or backward-incompatible.
Reproduction guide :beetle:
Observed behaviour: :eyes: :broken_heart: Lots of errors at init:
Also, layers are not properly initialized, so emacs just ends up being thoroughly broken.
Expected behaviour: :heart: :smile: No errors at init time.
System Info :computer:
Backtrace :paw_prints: