Let's dogfood my own extension api and build a display for buffers, similar to vsc. It's certainly been asked for often enough.
Some thoughts:
IMO option to group them by project will be useful too .
As a side note, you may need to solve the multiple roots issue, right?
As a side note, you may need to solve the multiple roots issue, right?
Not sure why you'd think that. Buffer nodes' paths will be quite different from the rest.
Are you planning to nest buffers in the treemacs view or they will be in a separate window? If you have separate window IMO you will need multiple roots.
Same window. The buffers will be an extra "project" at the very top, same as vsc. Multiple windows to switch through is something to think about later.
I would suggest adding some keybindings to switch categorization and/or ordering of the buffers.
IMO adding so many keybindings will be hard but there should be a configuration option/function for the purpose which can be easily modified by the user.
IMO option to group them by project will be useful too .
I would suggest adding some keybindings to switch categorisation and/or ordering of the buffers.
First the main course, then the dessert. For now I'm stuck in implementation details (and the backlog).
Are you planning to nest buffers in the treemacs view or they will be in a separate window?
Now that I think about it some kind of split window approach would have advantages. It would allow files and buffers to be visible at the same time and fix the follow/hl-line-mode question. Of course tracking and selecting those windows would be quite the nightmare in its own right.
If you have separate window IMO you will need multiple roots.
If you put it like that I am suddenly not sure what multi-root issue you mean. Please elaborate.
IMO adding so many keybindings will be hard
Don't need a keybind for all that. Just make the selection interactive, same as git-mode.
And a couple more implementation thoughts, while I'm at it:
There's an annoying weakness in the extension api. The first element of the key of a top-level extension like the buffers is its project struct. In a case like this other than being used for position storage it does nearly nothing - its name is "Buffers" and since it doesn't point to a file its path is 'Buffers as well. But if you want to address this tree's nodes you need that object anyway. To fix that I'll be amending the api such a top-level extension named "foo" will store a reference to its project struct in a buffer-local variable named treemacs-foo-extension-project. That will be very relevant for you @yyoncho if you still plan to migrate dap's visuals to treemacs (or does tree-mode do the job?).
Then there's the buffers themselves. Everything in emacs is a buffer, so everything that happens in emacs, both its core and its packages, spawns - and quickly discards - dozens, sometimes hundreds, of buffers (For example just calling M-x with helm would spawn about 200 temp buffers). Not exactly the best foundation when you want to minimise your footprint. This problem is compounded by the absence of a hook for buffer creation (quite understandable, considering how often temporary buffers are spawned).
The best way I've come up with to defeat these obstacles it as follows: to get a hold of buffers I need to track I will use after-change-major-mode-hook. This greatly minimises the number of hook calls made, eliminates a large category of "boring" buffers and allows me to make my own should-I-ignore-this checks. It also eliminates the need for use the global kill-buffer-hook, since I now know which buffers are interesting I can simply apply my hook locally.
The few downsides of this approach is that it won't track fundamental-mode buffers, and might miss actual major-mode changes, and I think I can work around the latter.
@Alexander-Miller
That will be very relevant for you @yyoncho if you still plan to migrate dap's visuals to treemacs (or does tree-mode do the job?).
Yes, but this is not top priority. First, I want to implement a viewer for lsp-mode errors in tree format(projects in the root, files and then errors. The projects + files will be fontlocked based on whether they have errors or not.
If you put it like that I am suddenly not sure what multi-root issue you mean. Please elaborate.
I am talking about this:
https://github.com/Alexander-Miller/treemacs/issues/263#issuecomment-451769203 - this is kind of a blocker for error list
Wanted to ask if you have seen https://github.com/DamienCassou/hierarchy ?
hierarchy
Ran into it a while ago, even played around with it a little. It seemed to precompute all nodes when I asked it to show some files. I doubt it could fit all of treemacs demands what with my parallel python processes, extension api hooks all over the place, the pseudo-dom, need for quick navigation and quick redisplay (how many other packages have unrolled loops like I'll be pushing soon in treemacs?).
Wanted to reference ibuffer-sidebar: https://github.com/jojojames/ibuffer-sidebar and ibuffer-projectile: https://github.com/purcell/ibuffer-projectile
Using the mode hook, it is possible to control grouping by project. This looks similar in intent to Buffer Display Extension, however it is text only and is missing iMenu integration.
I did look at ibuffer when looking for inspiration on how to hook into the buffers' lifecycle (ibuffer just grabs some prime real estate in post-command-hook like it owns the place). All those fancy features will come around later, for now I just want to get the basics going.
I will finally be tackling this after https://github.com/Alexander-Miller/treemacs/issues/677 is done.
I'll also look into using for the grouping and filtering part. If it goes well I can publish this extension as a new treemacs-bufler package.
FYI @alphapapa
Most helpful comment
I will finally be tackling this after https://github.com/Alexander-Miller/treemacs/issues/677 is done.
I'll also look into using for the grouping and filtering part. If it goes well I can publish this extension as a new
treemacs-buflerpackage.FYI @alphapapa