Add sorting support

[sayanarijit]

Closes: #58

[sayanarijit]

Hey @maximbaz please review when possible.

[sayanarijit]

[maximbaz]

Hello! Very happy to see this PR 🙂

1. First of all, I just love the sort+filter panel on top, brilliant idea 👍

2. I feel like icons should match:

   

3. With just relative search, shouldn't CODE... be after Cargo..., not before?

   

4. How to sort by absolute path? I see you have it in code, but not sure when that is enabled, i.e. how to test it.

5. Sort by node type is currently looking like this:

   

   I'm trying to think how to achieve such that directories and symlinks to directories are sorted together by relative path, and correspondingly files and symlinks to files are sorted together. It seems like we need to make sorter field in the config an array, instead of a single value, such that my sorting would become:

           messages:
             - AddNodeSorter:
                 sorter: [ByIsFile, BySymlinkIsFile, BySymlinkIsBroken]
             - AddNodeSorter:
                 sorter: [ByIsDir, BySymlinkIsDir]
             - AddNodeSorter:
                 sorter: ByRelativePath
             - Explore

   Do you agree, or am I overlooking something?

6. What is ByIsSymlink? If we have symlinks to files, dirs and broken, what is that group?

7. It seems I cannot override modes.builtin.sort in my config, nor add a new key in there.

Enough for now 😄

[maximbaz]

this is a bit suspicious, relative or absolute?

[sayanarijit]

Bug... Nice find...

[sayanarijit]

Hello! Very happy to see this PR 🙂

1. First of all, I just love the sort+filter panel on top, brilliant idea 👍

Thanks. 😃

1. I feel like icons should match:

The icons aren't tied to the app. I'll create separate customizable UI components for the sort and filter items.

1. With just relative search, shouldn't CODE... be after Cargo..., not before?

The default sorting logic thinks all CAPS are of lower value that the small case, i.e. O < a. I think we can workaround this by first comparing case insensitively then with the proper case. But that will add performance cost. Not sure if it's worth it.

1. How to sort by absolute path? I see you have it in code, but not sure when that is enabled, i.e. how to test it.

You can't sort nodes by abs path because alll the nodes will have the same parent. But you can sort by symlink's abs path using BySymlinkAbsolutePath. But I see what you mean i.e. to be able to sort by the node's and resolved symlink's abs path.

1. Sort by node type is currently looking like this:

   I'm trying to think how to achieve such that directories and symlinks to directories are sorted together by relative path, and correspondingly files and symlinks to files are sorted together. It seems like we need to make sorter field in the config an array, instead of a single value, such that my sorting would become:

           messages:
             - AddNodeSorter:
                 sorter: [ByIsFile, BySymlinkIsFile, BySymlinkIsBroken]
             - AddNodeSorter:
                 sorter: [ByIsDir, BySymlinkIsDir]
             - AddNodeSorter:
                 sorter: ByRelativePath
             - Explore

   Do you agree, or am I overlooking something?

Nice grouping... I need to use more brain power.

1. What is ByIsSymlink? If we have symlinks to files, dirs and broken, what is that group?

Haven't thought about grouping so far. So WIP.

1. It seems I cannot override modes.builtin.sort in my config, nor add a new key in there.

Bug. Will be fixed.

Enough for now 😄

[maximbaz]

You can't sort nodes by abs path because alll the nodes will have the same parent. But you can sort by symlink's abs path using BySymlinkAbsolutePath. But I see what you mean i.e. to be able to sort by the node's and resolved symlink's abs path.

Aaah I see. To be honest I don't think it's needed, I simply saw that in code and was curious how to invoke that code path 🙂 Sorting by relative path is by far what I would use, personally.

The default sorting logic thinks all CAPS are of lower value that the small case, i.e. O < a. I think we can workaround this by first comparing case insensitively then with the proper case. But that will add performance cost. Not sure if it's worth it.

Aaaah I see... There is of course eq_ignore_ascii_case, but to support unicode you might want to look into lexical_sort library, e.g. I'd definitely go for natural_lexical_cmp to also have numbers sorted naturally (or natural_lexical_­only_alnum_cmp, also looks interesting)

[sayanarijit]

[sayanarijit]

I left the case sensitivity to default since it seems trivial. Grouping sorters will add immense complexity. So left it at flat, but added more parameters to be able to achieve more without needing to group things.

[maximbaz]

I like the default sorting very much now 👍

I'm using exa with the arguments below (it's what I alias to la) and to me personally this is an ideal, very predictable, intuitive sorting, that's what I would like to try to get xplr to do (if it doesn't do this out of the box).

• When symlink is relative, they show it as relative path
• Intuitive sorting of "CODE" vs "Cargo" and all 20 "file_*" files
• No need to group broken links separately

[sayanarijit]

Got a nice idea. I can just use exa as a library instead of duplicating all the sorting and display logic.

[sayanarijit]

Wow exa comes with a performance cost. Try exa in /nix/store.

[sayanarijit]

ogham/exa#851

[maximbaz]

Interesting idea to make exa into a library! I haven't seen any noticeable impact in exa, but may be due to some hardware differences or what not... Also --git could be a slow flag. In any case, lets see what those guys reply to your suggestion!

[sayanarijit]

Hey @maximbaz I have reimplemented the path sorting using natord (like exa) for natural ordering and decided to publish the version with the current implementation and then look into exa to have a good base for comparison. So, need a final review.

[maximbaz]

Nice!

1. In the s (sorting menu), we have far less possibilities than what really exists. This is probably intentional, but I just wanted to confirm that it was not forgotten, did you add all the shortcuts that you wanted to into that list?

2. The default initial_sorting looks like this:

general:
  show_hidden: false
  initial_sorting:
    - sorter: ByCanonicalIsDir
      reverse: true
    - sorter: ByIsBroken
      reverse: true
    - sorter: ByIRelativePath
      reverse: false

Why is it, that if I change reverse: false in ByIsBroken or even remove that block completely, broken link is always last in xplr? Some config not applying properly, or am I missing something?

3. In default config in sorter_identifiers you are missing e.g. ByIRelativePath - if I override it, it works, so just a matter of having it in the config I guess. But ByRelativePath has rel as format, maybe ByIRelativePath should have irel or [i]rel as default instead of the current s?

[sayanarijit]

1. Yes... This is intentional. We can add more on user demand but too much can be confusing and difficult to remove later.
2. This is because we're sorting by directory first. Unlike exa we don't yet have a --group-directories-first option. So, using sorters to group by directory as of now. But the issue is that with broken symlinks, the sorting logic can't determine whether they're supposed to be pointing to directories or files. So it's being marked separately (neither directory, nor file, it's just broken).
3. Thanks. Fixed. [i]rel.

[maximbaz]

I see! I think it's all looking perfect to me! 🎉 ship it 🚀 😁