[RFE] Change the direction of display in header view

[manphiz]

Is your feature request related to a problem? Please describe.
mu4e-search-change-sorting accepts ascending and descending for sorting orders, where descending is the default so that you get the latest emails first which makes sense. However, the display of the mails is also from new to old. Personally I'd like to see the mail displayed from old to new (like in Gnus), but still prefer to query newer mails if possible.

Describe the solution you'd like
I did a rough code search and it looks like mu4e performs an mu find query[1][2] and display the result in header view. It may be possible be able to reverse the list in elisp but it could be slow. So it's probably worth considering adding a display-direction to mu to be able to reverse the results on demand.

Describe alternatives you've considered
(mu4e-search-change-sorting :date 'ascending) searchs the old mails first so not quite desireable.

[1] https://github.com/djcb/mu/blob/master/mu4e/mu4e-headers.el#L807
[2] https://github.com/djcb/mu/blob/master/mu4e/mu4e-server.el#L557

[djcb]

Changing the order just in the display is non-trivial., I recommend filtering by recent date in your query, and then ordering that in the desired direction.

[manphiz]

Thanks @djcb ! I wanted to avoid doing that in Elisp as I suppose that would be slow. I'm trying to see whether it's possible to reorder the recent message through Xapian queries but don't find an answer yet.

Also, the thread handling when query with reverse gets more complicated: messages in sub-threads are always newer than the parent message, but siblings are reversed from new to old. This was actually one of the main the motivations of this RFE as if I use ] to go to next new message in a thread, sometimes I read newer messages, and sometimes older messages, which could be confusing.

I wonder whether there is a way to let Xapian::MSet reorder the results by a field, which would make this much easier.

[djcb]

There are ways to do in on the Xapian level, but it's quite a bit of rework to implement that, hook it up with mu4e, test it etc., so, not planning this right now. Hence my recommendation to use filtering instead, even if that's not 100% what you want.

I suspect doing it in mu4e (the display side) is easier. It should be fast enough.

Anyway, I'll move this RFE to the IDEAS.org file, so we won't forget it; thank you for the suggestion!