unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Vladimir Panteleev <notmuch@thecybershadow.net>
To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org
Subject: Re: [PATCH 2/2] emacs: Add notmuch-update-search-tags
Date: Sat, 26 Aug 2017 01:50:08 +0000	[thread overview]
Message-ID: <41a586b8-5059-7190-3ae6-ab6017795c28@gmail.com> (raw)
In-Reply-To: <87r2vz7vfh.fsf@tethera.net>

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

  reply	other threads:[~2017-08-26  1:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-14  5:54 [PATCH 0/2] Update search results when tags change Vladimir Panteleev
2017-08-14  5:54 ` [PATCH 1/2] notmuch-tag.el: Fix minor grammar error Vladimir Panteleev
2017-08-23 11:11   ` David Bremner
2017-08-14  5:54 ` [PATCH 2/2] emacs: Add notmuch-update-search-tags Vladimir Panteleev
2017-08-25 11:12   ` David Bremner
2017-08-26  1:50     ` Vladimir Panteleev [this message]
2017-08-26  1:55       ` [PATCH v2] " Vladimir Panteleev
2017-08-26 10:23         ` Mark Walters
2017-08-26 17:15           ` Vladimir Panteleev
2017-08-27  7:46             ` Mark Walters
2017-08-29  1:18         ` David Bremner
2017-09-04 22:05           ` Vladimir Panteleev
2017-09-06 13:11             ` David Bremner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41a586b8-5059-7190-3ae6-ab6017795c28@gmail.com \
    --to=notmuch@thecybershadow.net \
    --cc=david@tethera.net \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).