Sorting with `name.<EXT PREFIX>.ext` is based on `<EXT PREFIX>` instead of `.ext`

[SirWrexes]

Description

Hey there,
I do quite often like to "namespace" my files in many projects.
For instance, with my Hyprland config, I have various environment settings files for my different apps, and name them 00-env.<APP NAME>.conf.
I've noticed nvim-tree sorts those based on <APP NAME> and they end up in a different spot in my file list than expected.

Neovim version

NVIM v0.9.1
Build type: Release
LuaJIT 2.1.0-beta3

Operating system and version

Linux 6.3.8-arch1-1

nvim-tree version

f5d970d

Clean room replication

vim.g.loaded_netrw = 1
vim.g.loaded_netrwPlugin = 1

vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvt-min/site]]
local package_root = "/tmp/nvt-min/site/pack"
local install_path = package_root .. "/packer/start/packer.nvim"
local function load_plugins()
  require("packer").startup {
    {
      "wbthomason/packer.nvim",
      "nvim-tree/nvim-tree.lua",
      "nvim-tree/nvim-web-devicons",
      -- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
      -- OP's note: No plugin necessary
    },
    config = {
      -- OP's note: this is the only change to nvt-nvim.lua I made
      -- It seems however that the default sorting mode has the same behaviour.
      sort_by = 'extension',
      package_root = package_root,
      compile_path = install_path .. "/plugin/packer_compiled.lua",
      display = { non_interactive = true },
    },
  }
end
if vim.fn.isdirectory(install_path) == 0 then
  print "Installing nvim-tree and dependencies."
  vim.fn.system { "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path }
end
load_plugins()
require("packer").sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua setup()]]
vim.opt.termguicolors = true
vim.opt.cursorline = true

-- MODIFY NVIM-TREE SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
_G.setup = function()
  require("nvim-tree").setup {}
end

Steps to reproduce

Make a bunch of files with same extension like, say .ext.
Have some of them have prefixes to their extension like, for example, .moo, .foo, .bar, .baz

This command will:

1. Make a temporary directory
2. CD into it
3. Create a few empty files
4. Start NeoVim with NvimTree open

cd $(mktemp -d) \
  && touch thing1.ext thing2.ext thing3.ext \
  && for prefix in moo foo bar baz; do touch thing1.$prefix.ext; done \
  && nvim +NvimTreeOpen

Expected behavior

Edited screenshot of my Hyprland config files for demonstration purposes

Actual behavior

Unedited screenshot

[alex-courtis]

I'm happy to class this one as a bug.

The documentation does not specify exactly what an extension is and the smallest is reasonable. This is consistent with nvim-web-devicons.

It may be necessary to sort by the next extension e.g.

00-ena.java.conf
00-env.java.conf
00-enz.java.conf

[moniquelive]

I tried to create a custom sort_by function and ended up finding out something curious:

The documentation states that the sort_by function would be called with two arguments: the files to be sorted.

But my custom sort_by function was called with the first argument containing all files and the second argument was nil.

By printing inside the body of the original 'extension sorter' I see its logic is never run, leaving the execution on the guard clauses.

[alex-courtis]

The documentation states that the sort_by function would be called with two arguments: the files to be sorted.

sort_by will only be passed one argument - the table of nodes. Perhaps the documentation is misleading; I'll review.

By printing inside the body of the original 'extension sorter' I see its logic is never run, leaving the execution on the guard clauses.

There are some odd things going on in there.

Add 2.a.b then 1.a.b and the files are sorted in the added order 2.a.b then 1.a.b

Following a refresh they will then be sorted 1.a.b 2.a.b. That's the order that the filesystem presents the files. Only extension is sorted, not the remainder of the file name.

[alex-courtis]

Complete solution: sort_by = "extension" orders by smallest extension, matching larger extension on equal, finally sorting by complete name.

I did toy with the idea of an optionl table of sort methods for sort_by, however "extension" is the only real use case, so this is not needed.

@moniquelive I see you are familiar with lua and the nvim-tree codebase, I'd be most grateful if you could post a PR to fix this once and for all.

[moniquelive]

Instead of changing the current behaviour, I propose a new type of sorting mechanism using vim's filetypes. @alex-courtis please validate if it makes sense.

[alex-courtis]

Instead of changing the current behaviour, I propose a new type of sorting mechanism using vim's filetypes. @alex-courtis please validate if it makes sense.

That's a much more elegant solution. Let's go with that.

[SirWrexes]

I could see a few cases where this can be a problem, mostly with modeline-defined filetypes.

• Some apps use a non-standard extension to their configuration files but a standard notation, that you can tell NeoVim about with a modeline.
  We could argue that having those files sorted next to files of the same format but with standard extension is a good thing, but that's up to the user's preference.
• I don't think NeoVim can be aware of a modeline at all without reading the file. So files without an extension (scripts in a bin folder for example, with mixed python, lua, bash, etc) wouldn't be sorted either and users expecting a filetype sort would probably be disappointed.
• If we wanted the modeline to have an effect, nvim-tree would have to read all the files in a directory node when it's expanded, and that could heavily slow it down.
• What about extensions like tsx not matching their filetype (typescriptreact in this case) ?
• What about people overriding some filetypes with others—I override json with jsonc to enable proper parsing of json files that use comments.

Another proposal would be to, yes, keep the original extension sorting method, but also add a new one called something like suffix that effectively does what this issue is about. 🤔
That would make it opt-in and wouldn't break the workflow of people using extension.

I don't mean that filetype sorting is bad, though. I'd be happy if this issue gave birth to two new features. 😀

[moniquelive]

@alex-courtis I updated following your suggestion although I found some weird cases:

• .h files are identified as nil in my env so they go to the bottom of the list
• both .hpp and .cpp are identified as cpp so they get grouped together

@SirWrexes I'll open another PR for the 'suffix' sorter, it's actually simple to implement
@alex-courtis I'll open another PR for the fallback suggestion for the C.extension sorter

[moniquelive]

@alex-courtis @SirWrexes created #2307 for the suffix sorter: sorting first by folders, then by dotfiles then by regular files - (with or without extensions)

[alex-courtis]

Thanks for the updates. I'll review next weekend.

I don't mean that filetype sorting is bad, though. I'd be happy if this issue gave birth to two new features. 😀

Yes please. They are both valuable, different use cases.

Another proposal would be to, yes, keep the original extension sorting method, but also add a new one called something like suffix that effectively does what this issue is about. 🤔

I'm actually happy to "fix" the existing extension sorter bug to use last as per fnamemodify("file.a.b", ":e"), however having both options would be most useful. We can come up with a good name when building.

What about extensions like tsx not matching their filetype (typescriptreact in this case) ?

Users will have to select one of extension or filetype. They can use a custom sort_by if the want further matching.

[alex-courtis]

I don't think NeoVim can be aware of a modeline at all without reading the file.

If we wanted the modeline to have an effect, nvim-tree would have to read all the files in a directory node when it's expanded, and that could heavily slow it down.

Absolutely. We don't want to add this massive overhead.

Any matching more detailed than filetype by name will need to be done by the user's sort_by, accepting the overhead.