unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Carl Worth <cworth@cworth.org>
To: Xavier Maillard <xma@gnu.org>,
	Mark Anderson <MarkR.Anderson@amd.com>,
	Jesse Rosenthal <jrosenthal@jhu.edu>,
	"notmuch\@notmuchmail.org" <notmuch@notmuchmail.org>
Subject: Re: Bulk message tagging
Date: Wed, 14 Apr 2010 17:59:01 -0700	[thread overview]
Message-ID: <87fx2xfs4q.fsf@yoom.home.cworth.org> (raw)
In-Reply-To: <m2wrwf76n3.fsf@deb.maillard.im>

[-- Attachment #1: Type: text/plain, Size: 3555 bytes --]

On Sat, 10 Apr 2010 15:56:48 +0200, Xavier Maillard <xma@gnu.org> wrote:
> On Tue, 6 Apr 2010 13:51:01 -0600, Mark Anderson <MarkR.Anderson@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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2010-04-15  0:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-04  4:37 Bulk message tagging Xavier Maillard
2010-04-04  4:56 ` Jason White
2010-04-04  5:27   ` Xavier Maillard
2010-04-04  5:46     ` Jason White
2010-04-05  6:19       ` Xavier Maillard
2010-04-04 11:38 ` Jesse Rosenthal
2010-04-05  6:15   ` Xavier Maillard
2010-04-05  6:44     ` Jason White
2010-04-06 19:51     ` Mark Anderson
2010-04-10 13:56       ` Xavier Maillard
2010-04-12 17:41         ` Mark Anderson
2010-04-15  0:59         ` Carl Worth [this message]
2010-04-15 20:04           ` Jesse Rosenthal
2010-04-15 20:17             ` Jesse Rosenthal
2010-04-16  1:46             ` Carl Worth
2010-04-16 11:47               ` Jesse Rosenthal
2010-04-17 15:43                 ` Carl Worth
2010-04-19  8:58                   ` David Edmondson
2010-04-16 13:57               ` Servilio Afre Puentes
  -- strict thread matches above, loose matches on Subject: below --
2010-04-17 18:32 Arian Kuschki
2010-04-21 23:02 ` Carl Worth
2010-04-23 20:05   ` Mark Anderson

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=87fx2xfs4q.fsf@yoom.home.cworth.org \
    --to=cworth@cworth.org \
    --cc=MarkR.Anderson@amd.com \
    --cc=jrosenthal@jhu.edu \
    --cc=notmuch@notmuchmail.org \
    --cc=xma@gnu.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).