New Columns and Sort Commands

[cseickel]

I just released a pair of cool new features that some people will like, and some won't. Those new features are:

1. If your window is wide enough (meaning position=current), it will show extra columns for Size, Type, and Last Modified. Created is available as well but disabled by default. See below for how to disable all of them.
2. You can also sort on these columns, even if they are not visible.
3. BONUS: You can also sort on git status and diagnostic errors, because why not go all the way on this?

The new sort is in addition to the existing sort functionality. If you sort by name, that is the old sort rules and options. If you sort by anything else, the name sort becomes the tie breaker. The default mapping for sorting is o + a letter for each choice of column. If you just hit o and pause the help sub-menu will pupup to guide you to the available choices.

Performance Impact

In my tests the impact was minimal, but it's perceivable if you are showing thousands of files and directories. It does do an extra lookup for each node to get these extra stats, and of course there is much more to render on the screen.

How to Disable

To disable the newly added columns, add this to your config:

require 'neo-tree'.setup {
  default_component_configs = {
    file_size = { enabled = false },
    type = { enabled = false },
    last_modified = { enabled = false },
    created = { enabled = false },
  }
}

If the columns are not used, and you don't sort by one of the fields that require it, there will not be any extra file stat lookups.

Extras

To make this happen the way I wanted it to work, I also added a few new utility features that you may find of interest:

• Components now have a required_width property that determines the minimum width of the window before that component is rendered.
• Components now have an enabled property. If enabled === false it will not be rendered. The default is enabled = true.
• The show_help command can now be configured to show a sub-menu, which is helpful for multi character commands. To use it, just pass a config object with a title and prefix_key:

["o"] = { "show_help", nowait=false, config = { title = "Order by", prefix_key = "o" }}

[miversen33]

Nice work! You moved quite quick on this :)

How's the documentation on this? Getting stat output has been on my list for netman for a while, so if you have done most of the leg work in getting it visualized for neo-tree, I will almost certainly "borrow" it for the netman integration, as long as I can puzzle through how to use it :)

[cseickel]

What you would need to do is to get this stat structure onto the nodes:

{                                                                                                                                                            
  birthtime = {                                                                                                                                                   
    sec = 1692617750                                                          
  },
  mtime = {
    sec = 1692617750
  },
  size = 11453,
}

That would make it just work as is.

What is probably better is to change all of the component functions in sources/common/components.lua to call state.get_stat(node) instead of utils.get_stat(node), so that all sources have an opportunity to provide stats in their own way. Then the ones that actually use the local file system can just relay that to the existing utils.get_stat.

This would make implementing get_stat a requirement for external sources.

[cseickel]

Is it possible to make get_stat an optional instead of a requirement?

Yes, it probably should be. Maybe it would be better instead call sources.manager.get_stat and implement it like this:

local get_stat_fn_cache = {}

---Get statistics for a given node, such as size, created time, etc.
---@param state table The state of the source.
---@param node table The NuiNode to get statistics for.
M.get_stat = function(state, node)
  if node.stat then
    return node.stat
  end
  local get_stat_fn = get_stat_fn_cache[state.name]
  if not get_stat_fn then
    local mod = get_source_data(state.name).module
    if type(mod.get_stat_source) == "function" then
      get_stat_fn = mod.get_stat
    else
      get_stat_fn = utils.get_stat
    end
    get_stat_fn_cache[state.name] = get_stat_fn
  end
  return get_stat_fn(node)
end

[miversen33]

That seems like it would be pretty clever. Here is where my head is currently.

A stat ui component is created (you may have this done already, I haven't dug through your commits yet), with some basic documentation on what information can be provided to it and how it will display said information.

Then sources (likely just the filesystem source and netman for now) can utilize that component, providing a valid node.stat table that matches what the component expects. And bam, we now have the ability to "easily" display stat information for inodes (local or remote) :)

The only thing I can see some issue with is how any new commands are handled that revolve around stat, but that very much seems like a "problem for the source implementer" to deal with :)

[cseickel]

A stat ui component is created (you may have this done already, I haven't dug through your commits yet),

Yup, the mapping is i:

The way I have written it is that anything that wants stats calls the util.get_stat(node) function. If we just change that to the manager.get_stat(state, node) function I proposed above, then all you would need to do is to implement a get_stat(node) function in your module that returns the stat table I outlined earlier.

After implementing that function, the global show_file_details command and the new components will just work.

[miversen33]

Makes sense to me! And that makes it really easy to implement. I like it :) If you could toss that required table structure somewhere so it can be referenced later (if you haven't already), that would be great. I will absolutely forget this entire conversation about 5 minutes from now lol.

Nice work!

[cseickel]

Thanks. I already put up a PR (#1121) and provided an example of how to implement the function:

https://github.com/nvim-neo-tree/example-source/blob/1be4d91d94875501cb4db1a61aa5155b6cd654bc/lua/example/init.lua#L19-L49

Of course that only works with the PR code. Let me know if you have any comments or suggestions on that before I merge it.

[miversen33]

Tagging @tmummert as they were the author of the initial discussion post #1104. Does this set of features address what you envisioned?

[tmummert]

The new features meet my expectations in every way!

Are there any plans to add an option for the default sorting method?

[cseickel]

I didn't think about that. It's not a crazy idea. Would you mind creating an issue for that? I'll implement it if there are enough people interested in that feature.

[tmummert]

I have opened the corresponding issue 1123.