I think that the secondary sort isn't really needed. What is needed is a stable sort, ie. the sort that keeps the original sequence of entries having equal sort keys. The current sort doesn't do it.
It would allow sorting with two or more keys at a rather low cost: to have a list sorted with keys A, B, C a user should perform the sequence of sorts C then B, then A.
I hope this solution is easy to implement even if the current sorting algorithm can't be replaced (by adding an additional sorting column initiated with the entry position in the sorted sequence and modifying comparing function).
Stable sort instead of secondary sort
Re: Stable sort instead of secondary sort
Thank you for your feedback witrak(),
Stable sorts would be ideal.
However, Everything cannot have repeating sort item data when fast sorting, as results are presorted.
Each sort item data must be unique.
In most cases, Everything falls back to sorting by name and then path. (eg: when sorting by size and two files have the same size)
Secondary sorts and advanced sorting are in development.
If you would like to try these now, please try the Everything 1.5 alpha.
Stable sorts would be ideal.
However, Everything cannot have repeating sort item data when fast sorting, as results are presorted.
Each sort item data must be unique.
In most cases, Everything falls back to sorting by name and then path. (eg: when sorting by size and two files have the same size)
Secondary sorts and advanced sorting are in development.
If you would like to try these now, please try the Everything 1.5 alpha.
I will consider an option to do this when there are only a few results.It would allow sorting with two or more keys at a rather low cost: to have a list sorted with keys A, B, C a user should perform the sequence of sorts C then B, then A.