[notmuch] Bulk message tagging

[Carl Worth]

On Sat, 10 Apr 2010 15:56:48 +0200, Xavier Maillard <xma at gnu.org> wrote:
> On Tue, 6 Apr 2010 13:51:01 -0600, Mark Anderson <MarkR.Anderson at amd.com> wrote:
> > 
> > I think that '*' is definitely an awesome command, but I wonder if we
> > shouldn't have another command for the notmuch-search buffer which means
> > 'tag all the threads that I can see in this buffer'.
> 
> This is exactly what my initial post asked for. '*' is not
> totally satisfying for me due to the "limitations" you
> exposed. Though It is a good and acceptable workaround for me.
> As said, I just have to pay attention to redo my search query
> before pressing the '*' key.

The other bug with "*" is that it doesn't give any visual feedback, (the
tag addition/deletion doesn't show up).

We could fix all[*] the bugs of "*" by changing it to simply call the
new region-based tagging function. The only concern I have with that is
that it might be significantly slower, (it will execute N "notmuch tag"
commands to tag the N threads in the current buffer, rather than just
one "notmuch tag" command with the same search).

But the command-line based "notmuch tag +/-<tag> <search>" will always
still be available for true "bulk" tagging, so maybe having "*" in emacs
be implemented the slower way would be fine.

I think the biggest concern I have with the performance is that if it
*is* too slow, then the user might interrupt it with emacs, and with the
current implementation that would lead to inconsistent display. That's
not specific to "*" though---that's a bug with the current region-based
implementation---it's just that "*" might make it much easier to hit.

-Carl

[*] Most all the bugs, at least. Even just a simple 'a' (or '+' or '-')
on a single thread is already doing something subtly different than it
should. It's tagging all messages in the thread, but that might be more
messages than existed when the thread-summary was created. So you might
see:

	[1/1] A. Bozo				Boring topic...

and decide to archive the thread, and never realize that what you
archived away was several messages that would have been displayed as:

	[3/3] A Bozo, B Wizard, C Wizard	Boring topic... [**]

if you had only refreshed first.

So we really should fix that bug and only manipulate messages that were
actually present when the search was performed. Note that 'a' inside of
the show view does not have this bug---it does only affect messages
displayed.

I'm not currently afflicted by this bug only because I'm running
"notmuch new" manually, before mail-reading sessions as opposed to
inside a cron-job or similar.

[**] This is similar to the "thread pattern" idea described by Joey Hess
here:

	http://kitenet.net/~joey/blog/entry/thread_patterns/

Our current one-line presentation of threads does a really lousy job of
letting the user see thread patterns like this. We should perhaps come
up with something better.

One "something better" I have in mind would be the ability to write
searches that could identify and tag threads according to these
patterns. Our current search syntax isn't powerful enough to express
these kinds of relations about messages within threads, but I would be
very interested in coming up with something that does.

The parts that Xapian can't easily support here probably wouldn't have
to be fast either---they could operate on the results of threads, which
are generally "small". At least, I hope nobody has threads with hundreds
of thousands of messages in them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100414/f9030af5/attachment.pgp>