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 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.
@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!
@jameshowell This is deeply on point!