Feature request: ability to sort dirbuf buffers differently

[andrewferrier]

Dirbuf seems really nice! I've been using vinegar, but have experimented with dirvish in the past, and have been looking for a modern NeoVim equivalent which mashes together both.

It would be really nice if Dirvish supported different sorting strategies for files. In particular, I'm one of those weirdos who likes all my directories listed first. Could there be a preferred sorting method listed in the setup for new dirbuf buffers?

[elihunter173]

You seem to have taken the same path through file manager plugins as me.

It certainly is possible and something I've thought about. Would an API like this be sufficient?

require("dirbuf").setup {
  fstate_compare = function(left, right)
    ...
  end,
}

fstate_compare would be a function taking two tables containing a fname, ftype, and path and returns true when the first is less than the second, like Lua's table.sort() comp argument. Here's a description of the table

• fname is a string containing the literal unescaped name of the directory without any suffixes (i.e. a directory named foo/ would have an fname of "foo")
• ftype is a string describing the type of the object. It has one of the following values: "file", "directory", "link", "fifo", "socket", "char", or "block"
• path is the full path of the object using platform-specific directory separators (i.e. \ on Windows and / on Linux and MacOS) without a suffix. By default fstate_compare compares by fname case-insenstively.

You can test out the feature on the branch sort-option. Please provide any feedback you have, especially on the name of the configuration option. I personally don't think it's great, but internally I call these tables FStates so that's where the name comes from.

With these changes, I think this config would do what you want. It sorts first by ftype and then by fname case-insensitively which does put all directories before files but also puts all symlinks together after everything else. Either way, this API should be sufficient to sort things however you like

require("dirbuf").setup {
  fstate_compare = function(l, r)
    if l.ftype ~= r.ftype then
      return l.ftype < r.ftype
    else
      return l.fname:lower() < r.fname:lower()
    end
  end,
}

[andrewferrier]

I think this is a really nice way to handle things; the function callback option gives the user the flexibility to sort however they like. I could imagine that in the first iteration you could just provide this option for "advanced" users like me; in future if you wanted you could provide some predefined callback functions that can be used directly e.g. fstate_compare = require("dirbuf").COMPARE_DIRSFIRST to make things easier to configure.

I do agree that fstate_compare is a bit obscure. How about just sort?

FWIW I've tested this and it seems to work perfectly, including the example you kindly put together for me.

The only thing that this approach doesn't immediately solve is if anyone wants to resort an already-open dirbuf. But I could imagine in future you could provide a function to do that (require("dirbuf").resort_now(x)), where x is the same function you pass into fstate_compare above - so the user can setup whatever keybindings, commands etc. they want.

[elihunter173]

How about sort_order? I prefer that to just sort which to me feels like a true/false setting. And I like the idea of having predefined callback function but I don't think I'll do that for now unless it turns out to be something people want.

Also, whenever you run :edit, enter, or save a directory buffer it will refresh it and resort it. Granted, neither of those work on a modified dirbuf, so I could see providing a resort function.

[andrewferrier]

Yep, sort_order is good. And predefined ones was just a potential enhancement, definitely not required IMO.

I guess I was thinking more about the case where a buffer is already open and someone wants to change the order (eg maybe I normally sort by filename but in this dir I want to sort by modification time). But that’s probably a corner case not worth worrying about right now.

On Mon, 17 Jan 2022 at 20:41, Eli W. Hunter @.***> wrote:

How about sort_order? I prefer that to just sort which to me feels like a true/false setting. And I like the idea of having predefined callback function but I don't think I'll do that for now unless it turns out to be something people want.

Also, whenever you run :edit, enter, or save a directory buffer it will refresh it and resort it. Granted, neither of those work on a modified dirbuf, so I could see providing a resort function.

— Reply to this email directly, view it on GitHub https://github.com/elihunter173/dirbuf.nvim/issues/5#issuecomment-1014873276, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA2EB5WYXHKTOQDLNP3NEDUWR5ILANCNFSM5MFKMZOA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

-- Andrew Ferrier @.***

[elihunter173]

Ah that makes more sense. I'll put that on my list of possible enhancements, but yeah I'm not likely to work on resorting an already open dirbuf soon

[elihunter173]

The sort_order option has now been merged to main in https://github.com/elihunter173/dirbuf.nvim/commit/8a8fa45cc1a5dd045be2be9186f2d31cb25d46f7

[andrewferrier]

Nice, thank you!