SPC SPC doesn't work

[tofuya]

Description

SPC SPC doesn't work. (M-x work)

The log output to the Message buffer is as follows.

SPC SPC-  which-key: There are no keys to show
SPC SPC SPC is undefined

SPC SPC stopped working at commit b7e1dee13f619646d9d419f518f6ba8d835bef41

Reproduction guide

– Start Emacs – Press SPC SPC

Observed behaviour: Pressing the SPC SPC will result in SPC SPC-, prompting me to continue entering commands.

Expected behaviour: helm-M-x(or perhaps spacemacs/helm-M-x-fuzzy-matching)

System Info :computer:

– OS: darwin – Emacs: 28.0.91 – Spacemacs: 0.999.0 – Spacemacs branch: develop (rev. ee3c558c8) – Graphic display: nil – Distribution: spacemacs – Editing style: vim – Completion: helm – Layers:

(emacs-lisp helm multiple-cursors treemacs)

– System configuration features: ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP $

[fantostisch]

Seems to be broken when not using a window system: emacs -nw file.txt. When using emacs file.txt, it does seem to work.

[lebensterben]

@tofuya @fantostisch Would it be fixed if you add evil-terminal-cursor-changer to dotspacemacs-excluded-packages in your ~/.spacemacs?

(I assume @fantostisch also uses macOS here.)

[fantostisch]

Adding evil-terminal-cursor-changer to dotspacemacs-excluded-packages does not seem to fix the issue.

Forgot to mention my setup, tested on Ubuntu 21.10:

System Info :computer:

• OS: gnu/linux
• Emacs: 27.1
• Spacemacs: 0.999.0
• Spacemacs branch: develop (rev. ee3c558c8)
• Graphic display: nil
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

  (markdown spell-checking xclipboard)

• System configuration features: XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON PDUMPER LCMS2 GMP

[lebensterben]

@fantostisch

Have you restarted your Emacs after you added it into dotspacemacs-excluded-packages? (Also if you're running a daemon you need to restart it as well)

---

If you've already restarted Emacs, try this:

Comment out these lines and then restart Emacs https://github.com/syl20bnr/spacemacs/blob/ee3c558c80bbadfa4c692936ab9502765a4867f8/layers/%2Bspacemacs/spacemacs-editing-visual/packages.el#L30 https://github.com/syl20bnr/spacemacs/blob/ee3c558c80bbadfa4c692936ab9502765a4867f8/layers/%2Bspacemacs/spacemacs-editing-visual/packages.el#L37-L38

[fantostisch]

I am not using a daemon and restarted Emacs. On startup I saw a message deleting evil-terminal-cursor-changer.

I just discovered that it only shows the SPC SPC- which-key: There are no keys to show message the first time pressing SPC SPC after opening Emacs. When pressing SPC SPC again, it works.

Tested with both the evil-terminal-cursor-changer disabled and enabled, commenting out the lines does not seem to fix the issue.

[lebensterben]

@fantostisch

Thanks for your explanation. I suspect evil-terminal-cursor-changer is the culprit because there's a reported bug about funny behaviours in terminal (on macOS).

Your finding can now rule out this possibility.

---

Next, try these:

• First, update your Emacs packages with SPC f e U, restart Emacs and see whether the same issue persists.
• If the last step doesn't work, please use git bisect to pin down a commit that first introduced this problem.

Also, what's your dotspacemacs-excluded-packages like?

[fantostisch]

After starting Emacs without disabling the evil-terminal-cursor-changer extension and without commenting code out, the log shows: spacemacs-buffer||propertize-heading: Symbol’s function definition is void: all-the-icons-material when using -nw. When not using -nw this is not shown. Might be related?

The same issue persists after updating the packages. The commit that introduced the problem is b7e1dee13f619646d9d419f518f6ba8d835bef41, the commit before (f2afab0c32c1dfb8e2bfd3d1c4c84c8db5a68c4b) works.

My dotspacemacs-excluded-packages does not exclude any packages:

   dotspacemacs-excluded-packages '(
                          ;; evil-terminal-cursor-changer
                                    )

[lebensterben]

@fantostisch It's a known bug as for symbol's function undefined.

To clarify, in b7e1dee does SPC SPC works? Or do you mean it's the commit that introduces "symbol's function definition is undefined"?

[fantostisch]

SPC SPC does not work in https://github.com/syl20bnr/spacemacs/commit/b7e1dee13f619646d9d419f518f6ba8d835bef41, b7e1dee13f619646d9d419f518f6ba8d835bef41 is the commit that introduced the bug. Just tested and the commit also seems to introduce the spacemacs-buffer||propertize-heading: Symbol’s function definition is void: all-the-icons-material message. When using the commit before (https://github.com/syl20bnr/spacemacs/commit/f2afab0c32c1dfb8e2bfd3d1c4c84c8db5a68c4b), it does not show this message.

[lebensterben]

@fantostisch Thanks for the clarification. Checkout any of the commit where SPC SPC doesn't work, for example latest develop. Then, open Emacs and type :(ielm) and it brings you to a buffer with inferior Emacs lisp mode. Then, evaluate the following expressions one at a time and paste the ouput:

(featurep 'all-the-icons)

(configuration-layer/package-used-p 'all-the-icons)

(fboundp 'all-the-icons-material)

(fboundp 'all-the-icons-octicon)

[fantostisch]

Run on the latest develop (ee3c558c80bbadfa4c692936ab9502765a4867f8):

ELISP> (featurep 'all-the-icons)
nil
ELISP> (configuration-layer/package-used-p 'all-the-icons)

t
ELISP> (fboundp 'all-the-icons-material)

nil
ELISP> (fboundp 'all-the-icons-octicon)
nil
ELISP>

[lebensterben]

@fantostisch This is very weird.

• (configuration-layer/package-used-p 'all-the-icons) returns t means that all-the-icons package is not excluded and is being used, as expected.
• But (featurep 'all-the-icons) returns nil meaning that it cannot find the package.

In your ~/.emacs.d/elpa/27.1/develop, is there a directory named like all-the-icons-* where * is a timestamp?

[fantostisch]

Yes, there is a all-the-icons-20220117.108 directory with the following contents:

~/.emacs.d/elpa/27.1/develop/all-the-icons-20220117.108$ ls -lh
total 180K
-rw-rw-r-- 1 nick nick 2,4K feb 10 12:17 all-the-icons-autoloads.el
-rw-r--r-- 1 nick nick  78K feb 10 12:17 all-the-icons.el
-rw-rw-r-- 1 nick nick  70K feb 10 12:17 all-the-icons.elc
-rw-r--r-- 1 nick nick 7,6K feb 10 12:17 all-the-icons-faces.el
-rw-rw-r-- 1 nick nick 6,2K feb 10 12:17 all-the-icons-faces.elc
-rw-r--r-- 1 nick nick  427 feb 10 12:17 all-the-icons-pkg.el
drwxrwxr-x 2 nick nick 4,0K feb 10 12:17 data

[lebensterben]

@fantostisch I don't have any explanation for that...

What's the result if you type features in ielm buffer?

---

Also: Can you try to update Emacs to latest version (27.2)?

[fantostisch]

Just tried 27.2 by using the Emacs snap package and it has the same issue. Using 27.2:

ELISP> features
(smartparens-config smartparens-text smartparens ielm pp highlight-parentheses diminish winner recentf tree-widget editorconfig-core editorconfig-core-handle editorconfig-fnmatch term/xterm xterm async ws-butler winum spacemacs-purpose-popwin window-purpose-x imenu-list hideshow imenu ibuf-ext ibuffer ibuffer-loaddefs evil-collection-dired dired dired-loaddefs etags fileloop generator xref project volatile-highlights undo-tree diff symbol-overlay string-inflection string-edit spacemacs-xclipboard spaceline-config spaceline-segments spaceline powerline powerline-separators powerline-themes saveplace savehist popwin persp-mode multi-line multi-line-find multi-line-enter multi-line-decorator multi-line-respace multi-line-shared shut-up multi-line-cycle multi-line-candidate hl-todo window-purpose window-purpose-fixes window-purpose-prefix-overload window-purpose-switch let-alist window-purpose-layout window-purpose-core window-purpose-configuration window-purpose-utils eyebrowse evil-unimpaired f s dash evil-textobj-line evil-terminal-cursor-changer color evil-easymotion evil-collection-buff-menu evil-collection annalist evil-anzu anzu editorconfig noutline outline drag-stuff column-enforce-mode clean-aindent-mode helm-easymenu hybrid-mode evil-evilified-state which-key use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key use-package-core hydra lv evil evil-integration evil-maps evil-commands reveal flyspell ispell evil-jumps evil-command-window evil-search evil-ex shell pcomplete comint ansi-color evil-types evil-macros evil-repeat evil-states evil-core evil-common windmove calc calc-loaddefs calc-macs thingatpt rect evil-digraphs evil-vars ring bind-map info quelpa mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr lisp-mnt help-fns radix-tree hl-line xt-mouse autorevert filenotify cl-extra disp-table spacemacs-dark-theme spacemacs-common format-spec finder-inf ido-vertical-mode ido core-spacemacs core-spacebind core-use-package-ext core-transient-state core-micro-state core-toggle core-keybindings core-fonts-support core-themes-support core-display-init core-jump core-release-management core-custom-settings core-configuration-layer core-progress-bar core-spacemacs-buffer core-funcs spacemacs-ht inline help-mode warnings package browse-url url-handlers url-parse auth-source cl-seq password-cache json map url-vars eieio eieio-core eieio-loaddefs epg epg-config core-command-line core-debug edmacro kmacro derived profiler core-hooks page-break-lines easy-mmode core-env load-env-vars rx core-dotspacemacs advice pcase core-customization validate cus-edit easymenu cus-start cus-load wid-edit seq byte-opt bytecomp byte-compile cconv core-emacs-backports core-compilation core-dumper subr-x spinner cl-macs gv cl-loaddefs cl-lib core-load-paths core-versions core-early-funcs tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

[lebensterben]

@fantostisch Can you post your .spacemacs?

[fantostisch]

My .spacemacs: spacemacs.txt

[lebensterben]

@fantostisch Your .spacemacs looks perfect...

Can you post the value of load-path?

[fantostisch]

load-path: load-path-nw.txt

[lebensterben]

@fantostisch This is very strange, in your load-path you can see "/home/nick/.emacs.d/elpa/27.2/develop/all-the-icons-20220117.108"

In ielm, can you try again with:

(featurep 'all-the-icons)

(require 'all-the-icons)

[fantostisch]

ELISP> (featurep 'all-the-icons)
nil
ELISP> (require 'all-the-icons)
all-the-icons

[fantostisch]

After executing the require command, the output of the featurep command changes:

ELISP> (featurep 'all-the-icons)
nil
ELISP> (require 'all-the-icons)
all-the-icons
ELISP> (featurep 'all-the-icons)
t

[lebensterben]

@fantostisch Thanks for the feedback. This time let's turn on debug-on-error for Emacs (in terminal) with

emacs -nw --eval '(setq debug-on-error t)'

If any error occurs, please attach the log.

[fantostisch]

An error occurred: error.txt

[lebensterben]

@fantostisch Thank you very much. In you ~/.emacs.d/core/core-spacemacs-buffer.el, try to replace (defun spacemacs-buffer||propertize-heading ..) by the following:

It seems like I didn't submit the correct fix last time.

(defmacro spacemacs-buffer||propertize-heading (icon text shortcut-char)
  `(concat (when dotspacemacs-startup-buffer-show-icons
             (concat ,icon " "))
           (propertize ,text 'face 'font-lock-keyword-face)
           (propertize (concat " (" ,shortcut-char ")")
                       'face 'font-lock-comment-face)))

[fantostisch]

In you ~/.emacs.d/core/core-spacemacs-buffer.el, try to replace (defun spacemacs-buffer||propertize-heading ..) by the following:

This fixes the issue! Thanks!

[lebensterben]

@fantostisch Does it also fix SPC SPC?

[fantostisch]

Yes, SPC SPC works now

[lebensterben]

@fantostisch Thanks for your bug report and cooperation. I will push the patch to develop.

[lebensterben]

@tofuya Please update Spacemacs and it should be fixed now.

[tofuya]

It has been fixed. Thank you for your quick response.

[dromaludaire]

@lebensterben I confirm your latest commit fixes the issue when using spacemacs-base. Thanks a lot!

[dszakallas]

I had a similar issue, i.e SPC SPC stopped working for me while M-x continued to work. In my case it wasn't related to all-the-icons.

This is what I found out by attaching the debugger with emacs -nw --eval '(setq debug-on-error t)':

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  set-buffer(nil)
  (save-current-buffer (set-buffer (get-buffer spacemacs-buffer-name)) (if dotspacemacs-startup-lists (progn (spacemacs-buffer/insert-startup-lists))) (spacemacs-buffer//insert-footer) (if configuration-layer-error-count (progn (spacemacs-buffer-mode) (face-remap-add-relative 'mode-line '((:background "red") mode-line)) (spacemacs-buffer/set-mode-line (format (concat "%s error(s) at startup! " "Spacemacs may not be able to operate properly.") configuration-layer-error-count) t)) (spacemacs-buffer/set-mode-line spacemacs--default-mode-line) (spacemacs-buffer-mode)) (force-mode-line-update) (spacemacs-buffer/goto-link-line))
  spacemacs-buffer//startup-hook()
  spacemacs/startup-hook()
  run-hooks(emacs-startup-hook term-setup-hook)
  #f(compiled-function () #<bytecode 0x110de7844d374a6c>)()
  normal-top-level()

I don't know what happens here exactly, but at some point this code tries to retrieve the spacemacs buffer with (get-buffer spacemacs-buffer-name), which becomes nil. I checked my .spacemacs file which had

(kill-buffer "*spacemacs*")

in my dotspacemacs/user-config, which I added as an attempt to remove the spacemacs buffer on startup, as suggested here. Commenting it made SPC SPC work again. I think I had this error since the day I included this hack, however I only recently started seeing an issue, so I didn't pay attention. But I am still searching for a valid way to get rid of the spacemacs buffer flashing up on startup.

[pataquets]

Same here (develop branch, commit 6f5de5c up-to-date as of today):

• TTY Emacs 28.1, kelleyk's PPA under Bionic (nativecomp not compiled).
• SPC SPC stopped working, with error message only on first attempt, silent thereafter.
• Spacemacs' home buffer gets cut after printing the upper three link rows. No recent files dashboard.

At first I blamed recently installed Emacs 28.1, but temporarily rolling back to 27.1 made no difference (no 27.2 available from PPA).

[rinconjc]

This issue seems to have reappeared in the latest commit b74da79db There are warning in the message buffer during start up:

Package ‘all-the-icons’ isn’t installed
(Spacemacs) --> deleting cmake-mode... [1/1]
Would have removed package cmake-mode but this is a system package so it has not been changed.
byte-code: Invalid function: org-assert-version
Package cl is deprecated

[rinconjc]

It seems the org-assert-version is defined in org-9.6, so installing it manually, (and adding it to dotspacemacs-additional-packages) fixed the above issue.

[abellmann]

I also have issues with 'org-assert-version' after an update of spacemacs. I downgraded spacemacs to commit 7991003a08662 (the one before org was upgraded to 9.6) and now I can work again. Can this be fixed by configuration (i.e. downgrading org-mode only) ?

[lebensterben]

@abellmann

There are discussions on org-assert-version on the mailist.

@dalanicolai what's your thought on this?

[lebensterben]

to people still experiencing this issue:

1. Please first try revert to this commit https://github.com/syl20bnr/spacemacs/commit/7991003a086622b03b30184aa51b45373823a2c8
2. If it doesn't fix the issue, what's you editing style (emacs or vi)? are you running emacs in terminal?

[dalanicolai]

I am not sure when (I guess it mostly happens correctly) the upgrade to org-9.6 introduces this error. What I am more or less sure about, is that this error appears because org-assert-version is a macro defined in org-macs.el, and it should get loaded before any other file using it gets compiled (generally all such files should require it in an eval-when-compile, but I guess not all of them have that included).

I guess if any such org-assert-version error occurs, it can be fixed by recompiling all org-....el files, which is probably easiest and most reliably done by deleting the org-9.6 directory from your .emacs/elpa/.... directory and subsequently restarting Spacemacs.

I am not sure what is the best strategy to prevent/fix this. At least, I guess users should generally quickly find the solution here now (if this is it, but I guess it is).

After writing this, I have also found this explanation. And the same thread mentions that it should have been fixed now.

[abellmann]

I tried a lot of things yesterday, including trying to delete the complete elpa folder and org-9.6 individually without any success (emacs 28.2 on wsl). The only solution for me was downgrading spacemacs. The issue mentioned by @dalanicolai also says, that the issue is not solved

[abellmann]

is there a functionality to select the org-mode version I would like to use or to use the built-in version? If not, could this be added?

[dalanicolai]

This commit might be interesting to you. Don't forget to remove the org directory from your .emacs.d/elpa directory after 'downgrading' org.

I am not aware of any other way to put 'restrictions' on the org-version.

[lebensterben]

I forgot to post the link of the discussion from org-mode's mail list: https://list.orgmode.org/87bkonzisl.fsf@gnu.org/T/#u

@dalanicolai Please take a look. It seems like the upstream has messed up this time.

[dalanicolai]

@lebensterben Thanks for the link. It confirms what @smile13241324 mentions in https://github.com/syl20bnr/spacemacs/issues/15861#issuecomment-1369257149. I think Maxi is trying to come up with a permanent fix (which indeed probably is not a straightforward thing to do). However, I am not sure if we need a permanent fix because all future org-modes will come with the org-assert-version macro. Therefore, I think we only need a temporary fix which would be to add the correct org-mode load path before the 'Spacemacs buffer' gets loaded.

Now I had a quick look, and it seems that the package-user-dir is already configured correctly at the first moment that the 'Spacemacs buffer' gets loaded (via spacemacs-buffer/goto-buffer in spacemacs/init).

Therefore, as I mentioned already, I guess that a quick temporary fix could be to add the correct org-mode dir to the front of the load path before that spacemacs-buffer/goto-buffer line in spacemacs-init as follows:

(let ((elpa-org-dir (car (seq-filter (apply-partially #'string-match-p "^org-9.*[0-9]$")
                                 (directory-files package-user-dir)))))
  (when elpa-org-dir
    (add-to-list 'load-path (print (concat package-user-dir elpa-org-dir)))))

so that the correct org-mode gets loaded already when creating the Spacemacs buffer. @smile13241324 What do you think? Could this work?

(No problem if that code stays there for a while... we will automatically get remembered about/to remove it when org-mode reaches version 10)

@lebensterben It is not so messed up, just it gives problems when users use org-mode before they load/configure it (so that the 'built-in' org-mode version gets (auto)loaded first)

[smile13241324]

Hmmm I think its worth a try, given that my hotfix wasn't that effective, I am definitely open for more drastic approaches now.

Once it works again we can take the time to check the details properly.

[smile13241324]

The side effects of my hotfix are fixed now, if you are still affected by an org version mismatch please report.