feat: don't consider "extensions" for directories when sorting

[sdht0]

$ mkdir a b.m c.n d.m e ; touch f.txt g.png h.png

$ eza --group-directories-first                              
a  b.m  c.n  d.m  e  f.txt  g.png  h.png

$ eza --group-directories-first --sort=extension
a  e  b.m  d.m  c.n  g.png  h.png  f.txt

The directories are also being sorted by extension based on the dot in the names. even though directories don't have extensions.

[cafkafk]

I don't think this technically classifies as a bug (as it is technically correct), but I'd love to see more input on whether this should be changed to reflect your desired behavior. Tentatively, I do agree that this should be changed, but I haven't thought much about it.

[sdht0]

One way to think about it is that directories have an implicit .dir extension and thus any other . in the directory name should be ignored.

I've found the current behavior surprising. For instance, when listing the installed packages on NixOS, I'd expect the multiple eza versions to be listed together. However, the *-eza-0.17.3 and *-eza-0.18.0 directories are sorted with other packages based on .3 and .0, which is not what I want. On the other hand, all files sorted by their extensions is what I want.

Given xkcd 1172, maybe eza can offer a new --sort=fileextension (or equivalent) option?

I do think the current behavior is a bug, but would be happy to be corrected as to why it is useful or expected.

[Omnikron13]

One way to think about it is that directories have an implicit .dir extension and thus any other . in the directory name should be ignored.

I find this is pretty horrifying way of thinking about it, ngl. =P

Shouldn't be a very tricky patch tbh, putting aside bikeshedding over how it should be handled.

[Omnikron13]

This is how it behaves if the sorting code just short circuits out to 'equal' if either the A or B input is a directory when it is asked to sort by extension.

[Omnikron13]

Crude fork that fixes this.