helm-projectile-find-file yields a "void variable symbolp" error

[svenpanne]

Description :octocat:

helm-projectile-find-file (M-m p f) doesn't work, it results in a "void variable symbolp" error.

Reproduction guide :beetle:

• Start Emacs
• Open dired in a project (e.g. some Git checkout)
• Do a helm-projectile-find-file (M-m p f)

Observed behaviour: :eyes: :broken_heart: "void variable symbolp" error and no prompt for file name

Expected behaviour: :heart: :smile: The usual helm behavior where you can type a subsequence of the file name

System Info :computer:

• OS: gnu/linux
• Emacs: 27.1
• Spacemacs: 0.999.0
• Spacemacs branch: develop (rev. 9acd34111)
• Graphic display: t
• Running in daemon: nil
• Distribution: spacemacs
• Editing style: emacs
• Completion: helm
• Layers:

(rust systemd octave asciidoc
      (c-c++ :variables c-c++-default-mode-for-headers 'c++-mode)
      csv go gpu graphviz
      (groovy :variables groovy-lsp-jar-path "~/.local/opt/groovy-language-server/share/groovy-language-server-all.jar")
      (haskell :variables haskell-completion-backend 'lsp)
      html
      (javascript :variables javascript-backend 'lsp js2-basic-offset 2 js-indent-level 2)
      lua perl5 protobuf
      (python :variables lsp-pylsp-plugins-pylint-enabled t lsp-pylsp-plugins-mccabe-threshold 37)
      racket
      (typescript :variables typescript-backend 'lsp typescript-fmt-tool 'typescript-formatter)
      windows-scripts yaml auto-completion emacs-lisp
      (helm :variables helm-buffer-max-length 24)
      (lsp :variables lsp-use-upstream-bindings t lsp-rust-server 'rust-analyzer cargo-process--command-clippy "clippy" cargo-process-reload-on-modify t)
      markdown multiple-cursors syntax-checking treemacs)

• 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

Backtrace :paw_prints:

Debugger entered--Lisp error: (void-variable symbolp)
  #f(compiled-function (source) #<bytecode 0x15673c5ccbb5>)(#<helm-source-sync helm-source-sync-15673d7011b4>)
  apply(#f(compiled-function (source) #<bytecode 0x15673c5ccbb5>) #<helm-source-sync helm-source-sync-15673d7011b4>)
  #f(compiled-function (&rest args) #<bytecode 0x15673c91715d>)(#<helm-source-sync helm-source-sync-15673d7011b4>)
  apply(#f(compiled-function (&rest args) #<bytecode 0x15673c91715d>) #<helm-source-sync helm-source-sync-15673d7011b4> nil)
  helm--setup-source(#<helm-source-sync helm-source-sync-15673d7011b4>)
  #f(compiled-function (name class &rest args) "Build a `helm' source named NAME with ARGS for CLASS.\nArgument NAME is a string which define the source name, so no need to use\nthe keyword :name in your source, NAME will be used instead.\nArgument CLASS is an eieio class object.\nArguments ARGS are keyword value pairs as defined in CLASS." #<bytecode 0x15673c5cca01>)("Projectile files" helm-source-syn

[lebensterben]

can you use git bisect to find the commit that brought this issue?

[samtux]

I confirm the same error in Debian 11 with emacs 27.1. Projectile does not work correctly.

apply: Symbol’s value as variable is void: symbolp [4 times]

[lebensterben]

I do see some errors but projectile works...

[svenpanne]

FYI: I have just moved away my old configuration and the .emacs.d/ directory and checked out the develop branch again. With that and the default configuration, helm-projectile-find-file works again.

I don't have a very complex configuration, but nevertheless, I guess there are probably some parts which just stopped working together. I'll have to re-enable things step by step to see where the breakage happens. That might take some time, so if somebody with a similar problem has more information, it would be good to know...

[svenpanne]

Hmmm, this is totally confusing, I had it working now and then, but with the following steps I can reproduce the "apply: Symbol’s value as variable is void: symbolp" problem consistently:

1. Nuke the previous installation/settings: rm -rf .emacs.d .spacemacs
2. Clone a fresh develop branch: git clone --branch develop https://github.com/syl20bnr/spacemacs $HOME/.emacs.d
3. Startup Emacs
4. Answer 2the questions with "On the planet Emacs in the Holy control tower (emacs)" and "The standard distribution, recommended (spacemacs)"
5. Restart Emacs, just for sure...
6. Dired (C-x d) into a standard Git checkout (e.g. [email protected]:autoconf-archive/autoconf-archive.git)
7. Try to do a helm-projectile-find-file (M-m p f) there => error

Can somebody confirm this?

[lebensterben]

please use git bisect to pin down the commit that breaks this.

[svenpanne]

OK, I travelled 2 months backwards in time, and all versions I've tried show the problem. But: IIRC, the problem showed up about only a week or two ago, so this probably means that the bug was newly introduced in one of the downloaded package dependencies.

The big question is: How can I find out which package and how can I bisect that? I'm a bit clueless here...

[svenpanne]

After updating the spacemacs checkout and all packages, things work better now: When helm-projectile-find-file is used for the first time, one gets a "Warning (emacs): Helm source ‘Projectile files’: before-init-hook Should be defined as a symbol" warning, but things work after that.

I had a quick look at the helm repo, and yesterday's https://github.com/emacs-helm/helm/commit/1d066466feb786f3477f1e6b3278d6af54666177 seems to have fixed the initial issue. The remaining question is: Where is the remaining bug leading to the warning above? Spacemacs or helm itself?

[svenpanne]

One more data point: The initial symbolp-related bug has probably been introduced here https://github.com/emacs-helm/helm/commit/9a16c5bd0feeeeba5c198c29213ddb6bfbda7061. This commit introduced the warning message above, so perhaps spacemacs has beeon doing something wrong for quite some time and this only shows up now? Just guessing, could be something totally unrelated...

[lebensterben]

recently we've employed more byte-compile support so it's likely to see more warnings.

but this is just a hypothesis. I have not tried to find the cause of the warning yet.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!