projectile-switch-project does not show known projects outside search path

[yauhen-l]

Here is my projectile config:

(use-package projectile
  :ensure t
  :bind-keymap ("C-c p" . projectile-command-map)
  :config
  (setq projectile-project-search-path '("~/ws/" "~/ws-private/"))

  (setq projectile-switch-project-action 'helm-projectile)

  (projectile-mode +1))

I used to switch to my project at ~/.emacs.d a lot with C-c p p, but now this project never shows up.

I can only see projects that are in ~/ws and ~/ws-private directories.

However projects in sub-folders of those (e.g. ~/ws/subfolder/some-project) also never show up.

My projectile version installed from MELPA:

     Status: Installed in ‘projectile-20250209.605/’ (unsigned).
    Version: 20250209.605
     Commit: cdb22f6b588c8ffa508f6fda586ee1253c73490b
    Summary: Manage and navigate projects in Emacs easily.
   Requires: emacs-26.1
Required by: helm-projectile-20250207.2201, treemacs-projectile-20240131.2042
    Website: https://github.com/bbatsov/projectile
   Keywords: project convenience 
     Author: Bozhidar Batsov <[email protected]>
Other versions: 20250209.605 (melpa).


Projectile is a project interaction library for Emacs.
It provides a powerful set of features operating at the project
level, as well as simple heuristics to identify projects.

[bbatsov]

Is this something you can reproduce without Helm? I'm asking mostly because I haven't made changes to the project tracking logic recently, and it seems to work fine for me.

[yauhen-l]

Yes, if helm is disabled I get the same results.

[bbatsov]

Hmm. The tracking is done by this function, which is triggered by find-file-hook:

(defun projectile-track-known-projects-find-file-hook ()
  "Function for caching projects with `find-file-hook'."
  (when (and projectile-track-known-projects-automatically (projectile-project-p))
    (projectile-add-known-project (projectile-project-root))))

I'd suggested adding a breakpoint or a bit of logging in it to see if it's properly triggered for you.

[yauhen-l]

Thanks to some article on Emacs Redux I could setup a debug on this function.

By switching to a project I indeed go into debug and successfully add project as known to projectile.

However if I try to switch to ~/.emacs.d/ project (it has .git directory) I get this (not sure what it means):

Debugger entered: nil
  edebug--display-1(nil 0 before)
  edebug--display(nil 0 before)
  edebug-debugger(0 before nil)
  edebug-before(0)
  (edebug-after (edebug-before 0) 10 (if (edebug-after (edebug-before 1) 5 (and (edebug-after 0 2 projectile-track-known-projects-automatically) (edebug-after (edebug-before 3) 4 (projectile-project-p)))) (progn (edebug-after (edebug-before 6) 9 (projectile-add-known-project (edebug-after (edebug-before 7) 8 (projectile-project-root)))))))
  (closure (ivy-mode ag-ignore-list ggtags-completion-table eshell-buffer-name t) nil (edebug-after (edebug-before 0) 10 (if (edebug-after (edebug-before 1) 5 (and (edebug-after 0 2 projectile-track-known-projects-automatically) (edebug-after (edebug-before 3) 4 (projectile-project-p)))) (progn (edebug-after (edebug-before 6) 9 (projectile-add-known-project (edebug-after (edebug-before 7) 8 (projectile-project-root))))))))()
  edebug-default-enter(projectile-track-known-projects-find-file-hook nil (closure (ivy-mode ag-ignore-list ggtags-completion-table eshell-buffer-name t) nil (edebug-after (edebug-before 0) 10 (if (edebug-after (edebug-before 1) 5 (and (edebug-after 0 2 projectile-track-known-projects-automatically) (edebug-after (edebug-before 3) 4 (projectile-project-p)))) (progn (edebug-after (edebug-before 6) 9 (projectile-add-known-project (edebug-after ... 8 ...))))))))
  edebug-default-enter(projectile-track-known-projects-find-file-hook nil (closure (ivy-mode ag-ignore-list ggtags-completion-table eshell-buffer-name t) nil (edebug-after (edebug-before 0) 10 (if (edebug-after (edebug-before 1) 5 (and (edebug-after 0 2 projectile-track-known-projects-automatically) (edebug-after (edebug-before 3) 4 (projectile-project-p)))) (progn (edebug-after (edebug-before 6) 9 (projectile-add-known-project (edebug-after ... 8 ...))))))))
  edebug-enter(projectile-track-known-projects-find-file-hook nil (closure (ivy-mode ag-ignore-list ggtags-completion-table eshell-buffer-name t) nil (edebug-after (edebug-before 0) 10 (if (edebug-after (edebug-before 1) 5 (and (edebug-after 0 2 projectile-track-known-projects-automatically) (edebug-after (edebug-before 3) 4 (projectile-project-p)))) (progn (edebug-after (edebug-before 6) 9 (projectile-add-known-project (edebug-after ... 8 ...))))))))
  projectile-track-known-projects-find-file-hook()
  projectile-find-file-hook-function()
  run-hooks(find-file-hook)

And ~/.emacs.d/ is never added to known projects. After this error I also not able to visit other projects as well, until I call edebug-remove-instrumentation.

[bbatsov]

Seems like some NPE, but it's hard to tell from where exactly. When I'm playing locally with dummy git projects everything works just fine.

I'll add a bit of extra logging to help with the debugging this, but in the mean time you can tweak your code locally to print debug messages with (message ...) and see if this won't give you further insight as to what's going on.

[yauhen-l]

I enabled debug on error and now get this:

Debugger entered--Lisp error: (invalid-read-syntax "#")
  read("(\"~/ws/zzz/\" #(\"~/.emacs.d/\" 0 11 (help...")
  projectile-unserialize("/home/yauhen/.emacs.d/projectile-bookmarks.eld")
  projectile-merge-known-projects()
  projectile-add-known-project("/home/yauhen/ws/xxx-yyy/")

[bbatsov]

That's because of Helm inserting font-locked strings in the bookmarks file for some reason. See bbatsov/helm-projectile#185 and the related fix.

[gnufied]

Is this only helm thing? I do not use helm and still I observe this behavior. I think it started after I upgraded to latest release.

[bbatsov]

@gnufied The bookmark's file corruption is Helm-specific for sure. I'm not sure if you're referring to this or to the tracking of known projects not working properly for you.