Buffer Display Extension

[Alexander-Miller]

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:

• There's too many buffers in emacs, best group them by major mode (or something else).
• Include customizable filters
• I need icons for the root and group nodes (there's nothing good in vsc), single buffers' icons can be same as their filetype mostly.
• How to keep this thing up-to-date? There's a hook for killing buffers not nothing good for creation.
  I wouldn't want a hook running for every with-temp-buffer either. There are a lot of buffers thrown around.
• See what ibuffer or other sidebars do.
• What about follow-mode? hl-line-mode?

[yyoncho]

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?

[Alexander-Miller]

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.

[yyoncho]

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.

[Alexander-Miller]

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.

[Compro-Prasad]

I would suggest adding some keybindings to switch categorization and/or ordering of the buffers.

• Order:
  1. Most recent (time)
  2. Most used (count)
  3. Alphabetical
• Categories:
  1. No categories
  2. Project based
  3. Language based
  4. Major mode based
• Show/hide file and non file buffers
• Prioritize file and non file 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.

[Alexander-Miller]

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.

[yyoncho]

@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:
#263 (comment) - this is kind of a blocker for error list

[Compro-Prasad]

Wanted to ask if you have seen https://github.com/DamienCassou/hierarchy ?

[Alexander-Miller]

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?).

[AshKash]

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.

[Alexander-Miller]

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.

[Alexander-Miller]

I will finally be tackling this after #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

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Alexander-Miller]

Stayin alive.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Alexander-Miller]

Stayin alive.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Alexander-Miller]

Stayin alive.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[aspiers]

I'm still very interested in this feature, and I'm sure I'm not the only one - mentioning to prevent the stale bot from closing.

On a slightly more controversial note, I believe that stale bots tend to do more harm than good, and that issues should always be closed by a human based on some explicit reasoning. So my personal recommendation would be to disable it. But that's just my take; of course you are free to ignore :-)

[stale]

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

[c-alpha]

I will finally be tackling this after #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

Hello, I'm a looong time Emacser (homing in on the 4^th decade of using it, I'm afraid), and I have to shamefully admit having switched to treemacs only recently. It's marvellous, and would have saved me lots of time, had I only discovered it earlier.

One of the first things I thought could perhaps be missing was the buffer list, too. I also use bufler, so it seemed obvious wanting to something like that in treemacs's sidebar.

But the longer I think about it, the less I seem to want this. treemacs to me is about discoverability; it shows me what all is there I could be looking at but perhaps haven't yet. A buffer list OTOH is about what I have opened already, so am more likely being aware of. Example: I have 40-ish Org files open at all times, which get loaded via org-agenda-files, which in turn contains six directory names. I have no trouble jumping between all these buffers, and remembering that they are there. Thus, AFAIC, discoverability is not an issue I would need solved for switching buffers.

OTOH, if I wanted to see all those Org files in treemacs, I. could always define a workspace with my six directories.

Overall, it thus seems to me that this could perhaps be a non-issue? The long history of this issue, with no visible momentum for getting it closed (PR, that is), could be seen as indicative of it being a non-starter, too?

[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).