1. I agree that this is a good compromise for the need of sorting for
index.
* 2. And I concern a pre-mentioned sorting need - about file browser. We
need at least two levels: folder/file and then name. Could this be
considered to improve at the same time?
3. About qsort, (I don't know how mutt is coded with qsort , but I have
some experiences using qsort to do multiple-level sorting on files.),
my approach will focus on the fcmp() function(fed to qsort), which
you can have arbitrary levels of sorting like below:
fcmp(e1, e2)
{
for (i = 0; i < levels; i++)
{
sort_method_function_pointer = sort_with[i];
cmp = (*sort_method_function_pointer)(e1, e2);
if (cmp) return cmp;
}
return 0;
}
A logic like this avoids multiple uses of qsort or a special
mutt_qsort(). What it adds is just a for-loop and an array. It won't
probably have an impact on performance because most of comparison
will just stop at 1st or 2nd level.
best regards,
charlie
On Wed, Feb 06, 2002 at 01:13:13PM -0500, Daniel Eisenbud wrote:
> I've been planning to do this for a while.
>
> It seems to me that the only time that more than two levels of sorting
> is useful is when the first level is threads. If anyone can give me a
> plausible scenario where they'd want more than three, or more than two
> unthreaded, I'll think about my approach. But for the moment the right
> thing to do seems to be to break threading out into its own config
> variable. So you can set
>
> threads=forward
> threads=reverse
> or
> threads=off
>
> and then sort and sort_aux are what's used for secondary and tertiary
> sorting, or primary and secondary if threads=off. Make sense to people?
>
> -Daniel
>
