Requery #1558
Requery #1558
Conversation
That means I failed to describe it ;) In a search buffer, all displayed threads originally come from matching a query. In that sense only some of the messages in a thread are actual matches since not all messages necessarily match the query - a thread is "matched" as soon as one the messages in a thread matches the query.
Ultimately, that is what I want to have in the search buffer (patch 2). But even if you don't care about that display: If you ask for the newest datetime in a thread then it makes a difference whether you query for the thread ID alone or for that AND the original query. Before patch 1, alot sorts the seach buffer by one of those dates and displays the other. This can look quite confusing. After patch 1 always the same date is used, namely the one from the newest matching message. |
|
Quoting Michael J Gruber (2021-01-01 16:35:26)
I really don't see the problem that you're solving, sorry.
That means I failed to describe it ;)
In a search buffer, all displayed threads originally come from matching a
query. In that sense only some of the messages in a thread are actual matches
since not all messages necessarily match the query - a thread is "matched" as
soon as one the messages in a thread matches the query.
notmuch search date:today gives me a line thread:000000000001cf1a 11 mins. ago
[6/12] Patrick Totzke; [pazz/alot] ... for example. The thread with 12 messages
"mathched" because at least 1 message (in fact 6) match the query.
Yes, so far to old.
Ultimately, that is what I want to have in the search buffer (patch 2). But
even if you don't care about that display:
If you ask for the newest datetime in a thread then it makes a difference
whether you query for the thread ID alone or for that AND the original query.
Before patch 1, alot sorts the seach buffer by one of those dates and displays
the other. This can look quite confusing. After patch 1 always the same date is
used, namely the one from the newest matching message.
I think I see now. For instance if I have messages A<B<C in two threads {A,C} and {B}
and search mode sorts them by newest first then I have {A,C} newer than {B} but its date stamp derives from the oldest msg C.
Can this not be solved more easily by making sure that search mode displays the "right" date for a thread?
Notice that Thread has `get_newest_date` and `get_oldest_date`.
So you could make sure that if search mode sorts threads to have the newer ones above
then it should display the newest date for each thread instead of the oldest one..
|
No. It's not a matter of "new" vs. "old". It's a matter of "all messages in thread" vs. "matched messages in thread". They are different sets of messages, and so you might get different dates (whether newest or oldest). Now, one could forget about the search completely, of course (i.e. fix the sorting and leave the display). But if I have a search buffer say for After all, it comes down to how you view the search buffer/widget and |
|
I'll check what it would take to fix the sorting issue on the other end (leave the display as is but sort accordingly); achieving the count (matched/total) could be independent of that. |
|
OK, so the man page for
And this is exactly what So, I guess the first question is whether the search buffer in alot should correspond to the output of Now, it might be useful to have a search view corresponding to all messages in threads with matched messages, especially in terms of sort order: if you tag only the first message in a thread (as is usual) then notmuch and alot (with or without this PR) will sort by that first message's date even if there are much newer messages in the thread. This might not be what you want and makes it difficult to look for something visually. The solution is |
|
So, I have been using this feature a lot ( ;) ), and before merging (however likely or unlikely that is), I would like to amend this series by one more feature. It touches the same question as the question whether the whole series makes sense: Is My answer is obviously yes, and the series is a consequence. Note that this point of view affects also the answer to the question: Which messages should a |
Currently, the thread list for the search widget is created by re-querying the db by thread ids. This loses the "match" flag on individual messages in a thread, so that, e.g., get_newest_date() lookest at the newest message in the thread instead of the newest match, so that dates may look out of order. (The list is sorted by matched dates.) Thus, remember the querystring and re-query by thread id and the original query. This restores dates.
Now that thread objects remember the original query, enhance the mailcount to show the number of matched and total messages in a thread in the search widget analogous to `notmuch search`. The original width in the default theme was 5: two parentheses plus up to three digits. We need to increase this 2+3+3+1=9 now (parentheses, three digits for each of the counts, slash).
Implement a new `fullthreads` command which turns the current query quickly into a query for all messages in all matched threads.
Since the search buffer is a view to `notmuch search`, the tag commands act on matched messages in the same ways as `notmuch tag` does. Implement an option `--fullthread` that makes the tag commands act on all messages in a thread instead. It's often the more useful variant in the UI, and this was the behaviour when alot treated the search buffer as a buffer of threads (as opposed to a buffer of matched messages).
Depending on your point of view, `--all` means something different or the same for the tag commands in search and thread buffers. Provide an alias `--fullthread` for the `--all` option of tag commands in a thread buffer so that one can use the same key binding for acting on one full thread in either buffer.
Typically, a user wants to act an a full thread in a search buffer. This used to be the behaviour before the switch to the cffi notmuch bindings and the requery series. Use the new option to restore the old behaviour for the default key bindings.
|
I find this new "fullthreads" search mode command a bit strange: it just seems to replace the current query string, or rather opens up a new search buffer for a slightly modified one. |
|
I think you can consider most of my PR's on hold, except for "fix-toggletags", which I guess is merged now. Where is a good place for a more fundamental discussion? By that I mean design principles such as:
Even before the switch to nm2, I found alot's behaviour surprising in some cases; the switch added some more. I tried to "fix" some of this, but I guess I lack a clear picture of what behaviour to aim for. I'm not completely happy with the behaviour of As for the |
This mini-series addresses two issues related to the way threads are requeried: the initial query is by a search term, and further queries are by thread id.
The first patch addresses what I consider a bug: If, say, you respond to an e-mail then the search view for the inbox will show the date of your reply but sort the thread by the date of the latest message matching the inbox query. This can look strange.
The second patch uses the solution from the first patch (remembering the query) to achieve a look closer to notmuch's search result list: display numbers of matched messages within a thread in a search view.
The latter one may need some way to configure. [In fact I think I submitted or discusssed this before but couldn't find it, sorry.]