<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr">On Mar 6, 2020, at 10:47 AM, David Bremner <<a href="mailto:david@tethera.net">david@tethera.net</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><span>There is the following documentation in notmuch-search(1).</span><br><span></span><br><span> Note: The thread order will be distinct between these two options (beyond being sim‐</span><br><span> ply reversed). When sorting by oldest-first the threads will be sorted by the oldest</span><br><span> message in each thread, but when sorting by newest-first the threads will be sorted</span><br><span> by the newest message in each thread.</span><br><span></span><br><span>If what you are seeing is consistent with that, then I guess it's</span><br><span>officially not a bug.</span><br></div></blockquote><div><br></div><div>The documentation seems to be in error, assuming you have copied it correctly. It says the thread orders are not strictly inverse between the two options, but then describes them precisely inverse. </div><div><br></div><div>Perhaps the word “unread” was unintentionally elided by the doc author, such that you could correct with the capitalized addition:</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><font color="#000000"><span style="caret-color: rgb(0, 0, 0); background-color: rgba(255, 255, 255, 0);">When sorting by oldest-first the threads will be sorted by the oldest UNREAD<br> message in each thread, but when sorting by newest-first the threads will be sorted<br> by the newest message in each thread.</span></font><br></div></blockquote></div><div><br></div><div>This would match the behavior described by Tom. </div><div><br></div></body></html>