[PATCH 0/6] Sort by from and subject

[Jani Nikula]

On Sat, 30 Sep 2017, William Casarin <jb55 at jb55.com> wrote:
> Jani Nikula <jani at nikula.org> writes:
>
>> I think there are two considerations here:
>>
>> First, is this something we want to have? Is this generally useful?
>
> Sorting by from and subject are in most mail clients (mutt, gnus, outlook...)

Which of those display results as threads, and of those that do, how do
they sort the threads? In the notmuch case, the threads would be sorted
based on one of the matching messages. Which one should it be? For
current date based searches, the message used for sorting is also
selected based on date.

If we expand the sorting, perhaps we should also think about sorting by
relevance provided by Xapian. Not saying you'd have to do this, but I'd
like to figure out how all of this should work. The implementation
doesn't look particularly difficult, it's the design that's harder to
get right.

>> There's still the issue of From: and Subject: needing more heuristic for
>> useful sorting that I mentioned in id:87efrm70ai.fsf at nikula.org.
>
> I think I understand what you mean in id:87efrm70ai.fsf at nikula.org but I
> don't have enough knowledge of notmuch to implement what you're asking
> :(. I believe these are rare cases because I haven't ran into the issue
> you described?

Look at the subject line of this message. Should it be sorted starting
at "Re:", "[PATCH", or "Sort"? You could argue for and against any one
of them. Contrast that with the thread sorting above: If the matching
message in this thread changes from one with vs. without "Re:", the sort
placement of the thread could change considerably.

It's common for some corporate mail systems to switch "Firstname
Lastname" in messages to "Lastname, Firstname". Should we do something
about that?

Arguably we could do the sorting first, and think of ways to improve it
afterwards.

>> Second, if we decide we want this, IMHO the interfaces (both human and
>> the lib) need to split the sort key and sort order from the
>> start. Fixing it later on is not going to be fun.
>
> I agree, I figured that would have been a larger refactor so I decided
> not to mix it in with this one. I'll start working on a branch that
> addresses this.

Please wait for feedback from others first, to not waste effort based on
just my opinions. I don't make the decisions here. :)


BR,
Jani.