On 2017-08-25 11:12, David Bremner wrote:
One side effect of this seems to be a regression, namely that in the
current buffer the "visual history" of tag changes is broken. Previously
deletions were shown by red strike-through and additions by green
underline. The deletions are now removed by the global update, and
additions shown on the wrong tags.
Thanks for pointing that out. Fixed in v2.
Another aspect that is a bit surprising is that it doesn't change whether
threads actually match. For example if I have search for tag:inbox,
adding tag inbox to a thread won't cause the corresponding thread to
show up. This is maybe defensible, but it wasn't clear to me if it was
intentional.
It is certainly intentional, though only reluctantly so.
As far as I can tell, there is no way to update existing search buffers
efficiently AND correctly, where "efficiently" means not simply
performing the entire search query and repopulating the search buffer,
and "correctly" means updating the buffer for deletions and additions so
that the buffer contents would remain effectively the same before and
after a notmuch-refresh-this-buffer invocation.
notmuch-search is pretty slow; populating the "all mail" search result
takes well over two minutes here (comparatively, for Thunderbird it
takes no time at all). Refreshing all notmuch search buffers just
because a tag changed somewhere (like point moving over an unread
message in notmuch-show) is not a practical approach.
Even though it would be possible to calculate the intersection between
affected tags and a search buffer's query to find out which messages
have been added or removed as an effect of the tagging operation, that
still doesn't tell us where in the buffer the newly-added results would
need to be inserted. Just plopping them at the end is an option, but not
really a satisfying one. Same with duplicating the result ordering logic
from the backend in the UI.
Ideally, notmuch would offer a subscription mechanism, which would allow
clients to subscribe to live changes in search queries, and receive
updates as deltas from the original results. That's more of a daydream,
though.
In any case, I've updated the documentation of the variable to clarify
that it does not cause results to be added or removed, but only update
the display of the existing results.
--
Best regards,
Vladimir
_______________________________________________
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
