in reply to Jonathan Lamothe

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)

github.com/purcell/ibuffer-vc

#emacs #ibuffer

This entry was edited (1 day ago)

James Endres Howell reshared this.

in reply to James Endres Howell

in reply to Daniel Mendler

@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

in reply to James Endres Howell

in reply to Bharath M. Palavalli

@bmp @jameshowell @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.
in reply to Daniel Mendler

@bmp @jameshowell @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.
in reply to Daniel Mendler

@bmp @jameshowell @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.
in reply to Daniel Mendler

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

This entry was edited (8 hours ago)
in reply to James Endres Howell

@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
in reply to James Endres Howell

@James Endres Howell @Steve Purcell @Bharath M. Palavalli @Philip @Daniel Mendler 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.

in reply to Daniel Mendler

@minad @jameshowell @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!

This website uses cookies. If you continue browsing this website, you agree to the usage of cookies.

โ‡ง