treemacs fails to show anything when using native compiled code

[jtl5770]

I am using the following emacs version:
GNU Emacs 29.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8) of 2023-07-23

and I am updating my packages basically every day so I am on an up-to-date treemacs version from melpa as of today.

Since a couple of days (?) I have the problem that when I start treemacs, it opens the sidebar window, but doesn't display anything else. If I remove the compiled files from the eln-cache and restart emacs, and start treemacs right at the beginning before it has time to automatically asynchronously compile treemacs again, it works. If I wait too long, and the compilation has finished, it won't work of course.

So my assumption is that something breaks the correct functioning of the native compiled treemacs code.

[sebastiaanspeck]

Related to #1047?

[jtl5770]

Yes, commenting out doom-modeline actually makes it work again. I am just surprised that this only shows up in compiled form.

[sebastiaanspeck]

Maybe it will be fixed looking at my latest comment on #1047. Don’t know if that’s the best solution tho..

[talw]

Have the same issue as mentioned here and in #1047.

I also use compiled code.
Accordingly, If I eval-defun the function treemacs--setup-mode-line, the problem disappears.

[practicalli-johnny]

Also experiencing this issue in Spacemacs with the latest treemacs-20230809.2040 package. Emacs was built with native-compilation enabled and Doom modeline is being used.

As a temporary measure I've pinned an earlier version of treemacs from July which works correctly. The recipe builds a package called treemacs-20230703.202907

((treemacs
      :location (recipe
                 :fetcher github
                 :repo "Alexander-Miller/treemacs"
                 :commit "2c576bebccd56ec8e65f4ec5ed5de864d9684fbf"
                 :files (:defaults
                         "Changelog.org"
                         "icons"
                         "src/elisp/treemacs*.el"
                         "src/scripts/treemacs*.py"
                         (:exclude "src/extra/*"))))

For spacemacs this recipe was added to dotspacemacs-additional-packages with the treemacs layer configuration comment out.

I assume this approach will work with doom using the :pin option and the same SHA commit value.

[jtl5770]

the proposed fix doesn't work for me (no change - treemacs window still blank)

[fxkrait]

I'm just going to leave a comment here, because there was an earlier comment about pinning an older commit as a workaround, and I was looking into implementing that fix for my configuration, and the stuff below worked for me.

The error is a blank treemacs window with: Error in post-command-hook (treemacs--post-command): (wrong-type-argument number-or-marker-p nil), and I believe it might have (very likely) appeared after I switched from emacs28 to emacs29. (I also did a package upgrade with straight-pull-all, but I don't know how related that is, and can't remember if I upgraded packages after broken treemacs).

• (I believe this is a similar issue, and I got the native-comp .elc generating on the treemacs files per straight's build directory)

• I'm using emacs29 with straight.el and doom-modeline (if that matters here), and you cannot pin commits with straight, but there's lock files that let you do that I believe, but I only looked a little into that aspect.

• Anyway the fix for my setup is: Delete straight/build/treemacs, clear straight/repos/treemacs, download the 3.1 release, copy and paste those files into straight/repos/treemacs. Close and reopen emacs, straight will rebuild treemacs (using that downloaded repo), and things should work as normal.

  • This can be seen with just a basic: (straight-use-package 'treemacs)

So I'm still running the same 3.1 release according to treemacs-version, but now I have no errors.

Why this works? Don't ask me. I'm just a knob-tweaker over here.

• I'm not really sure what these package managers are doing entirely, but now that it works again, I can continue living in ignorance, and be alright.
  • (Issue reproduces if I let straight.el repopulate the repo directory by itself, and fixes when I manually set it from github. I don't see any issues in straight.el's issue tracker, so it might just be a me-thing, but it's curious, assuming I'm not the problem here.)

[andreyyao]

@greghab I have the same problem without using straight.

[fxkrait]

Just to clarify my previous comment and the behavior noted (there's nothing wrong with straight.el, it's working fine):

• straight.el by default is pulling in the current master: (Aug 9) 6a6171c, which has the error for me.
• Error starts from Aug 7 onward: e4a56c6
• Commits pre-Aug 7, such as (Jul 19) aa0944a or the 3.1 tagged release (Apr 8) 1274853 are fine.
• This commit from Treemacs + Doom Modeline on emacs 29.1 #1047 does not fix it, so [UI] Revert changes to show current workspace name for doom-modeline #1050 probably makes sense for now.

---

And just some misc notes below:

Also just in general instead of treemacs-version, the repo commit is a more accurate indicator of the real version being run, because treemacs-version is only manually bumped when the release tag is manually bumped, like for 3.1

• (And with straight.el, because it's just pulling git repos you can just temporarily git checkout whatever commit you want in straight/repos/treemacs, git log to double check the head is set correct, and rebuild whatever commit you want by just deleting the old build straight/build/treemacs)

[LionyxML]

I am on emacs 30 with no frameworks (doom, space, etc.) and also have this issue.

I install all my packages directly from package-list-packages where I have the MELPA repository enabled.

I have this version of treemacs installed: [Treemacs] v3.1 (installed 2023.08.14) @ Emacs 30.0.50 and doom-modeline 4.0.0. (melpa Version: 20230814.814)

While the PR of the good fella @sebastiaanspeck is not already merged and distributed, my workaround is ensuring treemacs is loaded BEFORE doom-modeline.

~/.emacs.d/init.el

;; commented this custom setting
;;  '(doom-modeline-mode t)
...
(treemacs) ;; turns on
(treemacs) ;; turns off (as I want it to start retracted)
...
(doom-modeline-mode 1)

This dirty workaround made treemacs work for me.

update: this worked while I had not switched to another project, as soon as doom-modeline is started no more treemacs :(

[sebastiaanspeck]

"Fix" is merged (reverted the breaking change). Please test the latest version

[jtl5770]

Works again :-)

[LionyxML]

Confirming, this is now working for me:

Treemacs: Version: 20230814.1949 / Commit: 8a1d66f5d658e9d0c0e752b97849271ee6734198
Doom-modeline: Version: 20230814.1704 / Commit: 9ce19994654b427679aad4bceb546afe64decb06

Thanks!

[fxkrait]

Works for me.

[Alexander-Miller]

We just pushed a new version of the modeline change. Let me know if it works for you.

[fxkrait]

Looks good to me. Workspace name appears as expected. Thanks for fixing the feature, and for resolving the original PR.

00e96c8

8a1d66f

[kurnevsky]

Hm, it's still broken for me. I use it with lsp-treemacs-errors-list. First time I call it I get Symbol’s value as variable is void: treemacs-workspace-name, and second time Error in post-command-hook (treemacs--post-command): (wrong-type-argument number-or-marker-p nil)
Edit: even plain treemacs doesn't work.
Edit: the error is

Debugger entered--Lisp error: (void-variable treemacs-workspace-name)
  treemacs--setup-mode-line()
  #<subr treemacs-mode>()
  treemacs--mode-check-advice(#<subr treemacs-mode>)
  apply(treemacs--mode-check-advice #<subr treemacs-mode> nil)
  treemacs-mode()
  treemacs--init()
  treemacs(nil)
  funcall-interactively(treemacs nil)
  command-execute(treemacs)

[kurnevsky]

Aha, it happens because I don't have doom-modeline as a dependency when treemacs is compiled. But I have it in runtime. I use nix for emacs dependency management, which provides dependencies at compile time only when they are specified by a package. So I need to add this dependency manually like this: kurnevsky/nixfiles@4f85b45 But this means that treemacs will be broken in nix for anyone else who uses it together with doom-modeline...

[kurnevsky]

One possible solution would be to avoid compilation of this peace of code by wrapping it to eval like (eval '(this should not be compiled)).

[jtl5770]

Works for me

[auxsvr]

I'm not using doom-modeline and I have the same issue as #1048 (comment). Two more error messages that might be related:

Hash table data is not a list of even length.
[Treemacs] The treemacs-extensions module is obsolete, treemacs-treelib should be used instead.

[Alexander-Miller]

I pushed a possible fix, try again now.

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

That change was made months ago and as far as I know all dependencies made the necessary updates. You are probably using an old version of a package like lsp(-treemacs).

Hash table data is not a list of even length.

Is this a treemacs message?

[kurnevsky]

as I know all dependencies made the necessary updates

We are still using it in lsp-metals: https://github.com/emacs-lsp/lsp-metals/blob/811f02e4416d208102350ea48404e0310ffea647/lsp-metals-treeview.el#L63 :)

[auxsvr]

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

That change was made months ago and as far as I know all dependencies made the necessary updates. You are probably using an old version of a package like lsp(-treemacs).

I was using the latest released version. The latest code from git seems to work.

Hash table data is not a list of even length.

Is this a treemacs message?

I think so. The full message is:

let*: Hash table data is not a list of even length

and it appears when I double click the directory in treemacs. Only the root directory appears, the rest is empty.

[stale]

This issue has been automatically marked as stale because it has not had recent activity (this bot only works as a reminder, it will not close issues).