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 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