On Sat, 30 Sep 2017, William Casarin <jb55@jb55.com> wrote: > Jani Nikula <jani@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@nikula.org. > > I think I understand what you mean in id:87efrm70ai.fsf@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. _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch