treemacs autoload issues with recent melpa?

[ldeck]

Version

• treemacs-version output: [Treemacs] v3.0 (installed 2023.03.10) @ Emacs 28.2

Issue

I'm finding that a number of autoloads appear to not be loading. So when I attempt to press '?' to activate the hydra commands, or seek to run M-x treemacs-common-helpful-hydra or M-x treemacs-common-helpful-hydra I get the following errors:

treemacs-common-helpful-hydra: Symbol’s function definition is void: defhydra
treemacs-advanced-helpful-hydra: Symbol’s function definition is void: defhydra

Work-arounds

I was seeing the same issue for simple commands like cf or cd to create a file or directory and had to add the following autoloads manually to my use-package "treemacs" --> :config section to make these work :

(autoload 'treemacs-create-dir "treemacs-file-management" nil t nil)
(autoload 'treemacs-create-file "treemacs-file-management" nil t nil)

It would be painful to have to do so for every autoload required to put treemacs into a working state, of course.

How do I fix treemacs?

use-package Configuration

Any improvements to the following to make treemacs fully functional would also be much appreciated. Thanks!

(use-package lsp-treemacs
  :after (lsp-mode treemacs)
  :commands (lsp-treemacs-errors-list)
  :config
  (lsp-treemacs-sync-mode 1)
  )

(use-package treemacs
  :bind (
          ("C-c t /" . treemacs)
          ("C-c t 0" . treemacs-select-window)
          ("C-c t 1" . treemacs-delete-other-windows)
          ("C-c t B" . treemacs-bookmark)
          ("C-c t d" . treemacs-select-directory)
          ("C-c t f" . treemacs-find-file)
          ("C-c t t" . treemacs-find-tag)
          )
  :defer t
  :defines (treemacs-project-follow-mode)
  :config
  (setq treemacs-python-executable "/nix/store/dyy9d6lkxsk7pzwmmyhj4in6sfhxp3ic-python3-3.11.1/bin/python3")
  (setq treemacs-follow-after-init t
    treemacs-project-follow-mode t
    treemacs-display-current-project-exclusively t
    treemacs-follow-mode t
    treemacs-filewatch-mode t
    treemacs-fringe-indicator-mode 'always)
  (treemacs-git-mode 'advanced)
  (add-to-list 'treemacs-pre-file-insert-predicates #'treemacs-is-file-git-ignored?)

  (autoload 'treemacs-create-dir "treemacs-file-management" nil t nil)
  (autoload 'treemacs-create-file "treemacs-file-management" nil t nil)
  ;;(autoload 'treemacs-common-helpful-hydra "treemacs-hydras" nil t nil)
  )

(use-package treemacs-icons-dired
  :after (treemacs)
  :defer t
  :hook (dired-mode . treemacs-icons-dired-enable-once))

(use-package treemacs-magit
  :after (treemacs magit)
  :defer t)

[ldeck]

Oh, I should have mentioned also... that when treemacs starts up I currently see this:

[Treemacs] The treemacs-extensions module is obsolete, treemacs-treelib should be used instead.

This may be coming from LSP, perhaps. I'm assuming for now that it's a separate issue.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.

[ldeck]

Oh, I should have mentioned also... that when treemacs starts up I currently see this:

[Treemacs] The treemacs-extensions module is obsolete, treemacs-treelib should be used instead.

This may be coming from LSP, perhaps. I'm assuming for now that it's a separate issue.

Ah forgot to close this as it was caused by a nix build of emacs that failed to trigger autoloads.

[Alexander-Miller]

Sorry that I didn't pick this up in time, I don't have much time for treemacs nowadays.

This may be coming from LSP, perhaps. I'm assuming for now that it's a separate issue.

AFAIK lsp should be using the new library, so an update should fix things. If not you can just grep for (require 'treemacs-extensions).

[ldeck]

Sorry that I didn't pick this up in time, I don't have much time for treemacs nowadays.

This may be coming from LSP, perhaps. I'm assuming for now that it's a separate issue.

AFAIK lsp should be using the new library, so an update should fix things. If not you can just grep for (require 'treemacs-extensions).

Thanks @Alexander-Miller , np. It looks like it's being required by lsp-metals, but yes is a separate issue. The above issue as I mentioned was caused by a particular regression in the nix build I was using.