One thing I love about #emacs is that even though the documentation is generally pretty good, in the cases where it's inadequate, it's still really easy to find and step through the relevant source for a feature to find the answer I need.

@me Over the weekend I was messing around with ibuffer, integrating my custom ibuffer groups with @sanityinc's ibuffer-vc (recommended).

I was surprised to discover that documentation for ibuffer (in since 22.1?) is ... sparsely documented. But it was fun to get it working because the code (and Steve's add-on) is

PERFECTLY LIMPID

(the real story here is that I have been waiting a lifetime to drop the phrase "perfectly limpid" for internet points and here is my opportunity)

https://github.com/purcell/ibuffer-vc

#emacs #ibuffer

GitHub - purcell/ibuffer-vc: Let Emacs' ibuffer-mode group files by git project etc., and show file state

Let Emacs' ibuffer-mode group files by git project etc., and show file state - purcell/ibuffer-vc

GitHub

@jameshowell @me @sanityinc I also use Ibuffer but I am slightly annoyed that point changes on auto update (in contrast to Buffer-menu-mode). I would like to fix this sometimes.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77210

#77210 - 30.1.50; ibuffer - preserve window position when updating - GNU bug report logs

@minad Never had enough buffers to notice...!

@me @sanityinc

@jameshowell @me @sanityinc Even for few buffers you will see the effect with ibuffer-auto-mode, since point always jumps back to the beginning. Extremely annoying or I am doing something wrong...

@minad My annoyance with ibuffer:

The filter groups are defined as a list (of lists), which (per the definition of list) has an order.

That order determines the logic of which buffers get assigned to which groups. That order also determines the order in which those groups get displayed.

Sometimes I want those orderings to be different. Which would require two lists.

Each element already has a name string, so a display-order list could reference elements in the filter-order list. But that gets complicated when some of the elements are generated dynamically, like from ibuffer-vc.

This annoyance is probably not worthy of the effort to rewrite the package with a different abstraction. Especially not the effort to do so without introducing breaking changes.

@me @sanityinc

@jameshowell @minad @me @sanityinc I’ve found buffler (https://github.com/alphapapa/bufler.el) fits my needs well.
GitHub - alphapapa/bufler.el: A butler for your buffers. Group buffers into workspaces with programmable rules, and easily switch to and manipulate them.

A butler for your buffers. Group buffers into workspaces with programmable rules, and easily switch to and manipulate them. - alphapapa/bufler.el

GitHub
@bmp @jameshowell @me @sanityinc Yes, bufler looks nice! Alphapapa has many great packages. But I have slightly different preferences regarding dependencies and library usage. In addition to bufler I would have to install these libraries: burly, dash, f, hydra, lv, pretty-hydra and s. This is pretty large footprint. I care about this for multiple reasons - supply chain issues and consistency on the Elisp level. To be clear, this should not matter much for most users.
@bmp @jameshowell @me @sanityinc @pkal I am by no means a package minimalist - I have many packages installed and I suggest that people take advantage of our large ecosystem. However I differentiate between packages on the user level and the library level. On the library level my preference is to rely on Emacs builtins for basic functionality (instead of dash, f or s). If crucial library functionality is missing it can be added to subr.el and then ported back via Compat.
@bmp @jameshowell @me @sanityinc @pkal Unfortunately it turns out that adding new functionality to subr.el sometimes leads to long emacs-devel discussions with little progress. Not all additions are not welcome, like the recently discussed file-to-string function. These are the gaps which are then filled by libraries like dash, f or s.

@minad Agreed. I think the point to stress here is that users can decide. Hydra, for example, always struck me as relatively bloated, buggy, and a little too idiosyncratic with respect to (at least my mental models of) Emacs internal and UI conventions. But obviously it was very popular! Let a thousand flowers bloom. Cherish the Four Freedoms :-)

@bmp @me @sanityinc @pkal

@jameshowell Actually I found Hydra pretty good and simple. It is a smaller variant of Transient. But given that Transient is now the standard why not rely on it? I agree with you that users should decide and I want to emphasize that on the user level the underlying libraries do not matter.
@bmp @me @sanityinc @pkal

@minad I mean I would never dream of using evil-mode. But I am glad that evil-mode people can depend on evil-mode. Follow your nose to the Emacs that is your Emacs.

@bmp @me @sanityinc @pkal

@jameshowell @sanityinc @bmp @pkal @minad That's the beauty of Emacs: if you don't like it, it's infinitely customizable, and you can massage it into something you do like (assuming you're willing to do some digging).

There's also something to be said for an out-of-the-box solution that's close enough. I just prefer the former.

@minad @jameshowell @me @sanityinc @pkal I haven’t gotten to the point of discerning between packages based on such criteria:-), I’ve been relying on packages that help provide the functionality I need. Maybe, sometime in the future I’ll start a screening process before I use them!