Provide a way to organize lsp-mode, dap-mode, lsp-treemacs popup windows

[yyoncho]

At this point, we have more than 10+ different windows across the projects and they are displayed using display-buffer-in-side-window. This is problematic since at some point the windows become very small and unusable(see screenshot). Traditional emacs user won't suffer that problem but still, I believe that if we provide a mouse-driven flow for managing the windows it will be beneficial even since the mouse could be replaced with https://github.com/noctuid/link-hint.el which for the record do support treemacs and also the lsp-treemacs controls. A potential solution will be to create an accordion control like vscode one. AFAIK gdb-many-windows uses tabs to solve that same problem.

CC @Alexander-Miller since most of our windows if not all are using treemacs as a rendering engine and he also might provide a solution.

[Alexander-Miller]

IMO this is out of scope for a purely treemacs based solution. My philosophy is that treemacs provides the means to display your trees. What extensions do with these buffers, whether they use side windows or child frames or whatever is not for treemacs do decide.

But anyway, here's what I would do:

Instead of indiscriminately splitting the side window I'd introduce a grouping mechanism that decides when to split and when to reuse a window, similar to what window-purpose is doing, but limited to our side views. Such a grouping (which is of course customizable) could look like this

((filetree) (dependencies symbols) (call-hierarchy class-hierarchy) (&rest))

If we start with just the file tree and call up the symbols view, we split. We show a class hierarchy, we split again. We want to explore dependecies, we reuse the window with the symbols view. The file tree is always present because it is alone in its group. Graphical tabs as in GDB would help, but IMO they're optional, and I'm not sure how difficult they are to implement (maybe the new Emacs27 tabs can be useful here, or we could make use of an existing package like centaur tabs?).

It should more or less work with treemacs' current show & hide functions, though hiding won't bury the entire side view. Atomic windows should help here.

Something like this will be very useful for my own plans for mu4e and maybe buffers extenions, so I was considering putting up a similar subview package already, but I'd be happy for some jolly cooperation with the lsp folks to create something more universally useful.

[yyoncho]

Instead of indiscriminately splitting the side window I'd introduce a grouping mechanism that decides when to split and when to reuse a window, similar to what window-purpose is doing, but limited to our side views.

Isn't that supported by display-buffer framework? You may configure the number of windows for side via window-sides-slots and then use display-buffer-alist to set where each buffer goes?

[Alexander-Miller]

Sounds like you know more about this stuff than I do. I never went farther than calling display-buffer-in-side-window.

[mpanarin]

@yyoncho Sorry for popin' in a relatively old discussion.

treemacs supports project system. With displaying several roots in one window.
Probably we can make a single window for lsp mode and single window for dap mode, while making different features of it as project?
Afaiu (correct me @Alexander-Miller if I am wrong), the only limitation of several roots in one window is that you can't travers the tree. I highly doubt that this is needed in lsp at all.

[yyoncho]

@mpanarin this discussion is not solved so it is fine.

Probably we can make a single window for lsp mode and single window for dap mode, while making different features of it as project?

Can you paraphrase?

Afaiu (correct me @Alexander-Miller if I am wrong), the only limitation of several roots in one window is that you can't travers the tree. I highly doubt that this is needed in lsp at all.

Grouping all dap/lsp windows in a single buffer is a potential solution. Not sure whether it will be usable though - e. g. one would like to see the expression window + current thread stack.

[mpanarin]

By projects I mean several roots in one treemacs window

[rileyrg]

while collapsible, the "projects" are always visible if I understand you correctly. each debugging entity eg locals, or breakpoints or stack frame should have their own usable, deployable, toggleable window IMO. Not least, that fits in well with winner-mode.