Treeview clobbers/competes with Treemacs file tree

[julianmichael]

Describe the bug When calling lsp-metals-treeview to open the treeview, it replaces the Treemacs file tree and causes it (if already open) to get in a bad state, where multiple copies of the file tree are listed and step over each other. The only way to fix it is to run treemacs-kill-buffer and reopen with treemacs.

Worse, this also seems to happen every time lsp-metals-treeview--refresh is called and the lsp-metals treeview is opened. So the file tree quickly gets duplicated a bunch in a normal workflow.

To Reproduce Run the following:

:treemacs

Navigate to a file and open a buffer.

:lsp-metals-treeview
:kill-buffer
:treemacs

It might depend on where your file is in the file tree, which seems to determine where the new duplicated project root steps on the previous file tree.

Expected behavior I certainly don't expect the treemacs file tree to get in a bad state. But more generally it seems like lsp-metals is competing with treemacs for the 0 slot in the tree view window/buffer (not sure of the exact semantics here).

It seems in lsp-metals-treeview.el that it starts at 0 in lsp-metals-treeview--refresh and lsp-metals-treeview--show-window. Changing these to 1 fixed this issue; now the metals treeview opens in a new window under the file tree and doesn't cause any weirdness. This is much preferred, as I'd rather not lose view of the file tree anyway.

Screenshots After navigating to a file and opening a buffer:

After killing the lsp-metals-treeview buffer(s), reopening the file tree, and scrolling to the top:

I can't delete the duplicated root/project node either, since treemacs thinks both are the "last" one. And expanding nodes near where the tree was clobbered produces weird behavior. Obviously it got in a bad state.

I'm using Spacemacs develop with the scala layer plus this package.

[kurnevsky]

Thanks for reporting this. I can't reproduce this though - when I open metals treeview it just replaces treemacs file tree. Then I can open it again and it doesn't get corrupted. Probably we should make a variable for initial slot and make it 1 as default? Because for myself I'm not sure I'd prefer metals treeview to be shown together with files tree - it makes a lot of panels and they become too small.

@dsyzling what do you think?

[dsyzling]

Sorry distracted with work at the moment. I'll have to see if I can reproduce these issues once I've swapped over to the new treemacs api. There are potentially a number of issues currently which could be related to the latest treemacs. I'll also reassess some of the implementation decisions.

@kurnevsky On the panel suggestion, yes it might make sense and I agree I wouldn't want to see a proliferation of panels - or at least allow the user to customise their own behaviour.

[julianmichael]

Thanks for your responses. In terms of making too many panels, in my case the compile panel is the only one I usually see so things becoming small wasn't an issue, but yeah it seems like making this particular thing configurable is probably a good idea.

Actually for me personally this issue has ended up not mattering, because I decided to unset lsp-metals-treeview-show-when-views-received and keep the LSP Errors View open instead, and that has worked great for me.

Still seems like a bug, but if nobody else can reproduce, it's probably better to wait on the upcoming changes.