unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Carl Worth <cworth@cworth.org>
To: Marten Veldthuis <marten@veldthuis.com>,
	notmuch <notmuch@notmuchmail.org>
Subject: Re: [PATCH 0/4] Make tags applied by 'notmuch new' configurable.
Date: Thu, 03 Dec 2009 22:17:52 -0800	[thread overview]
Message-ID: <87r5rbfejz.fsf@yoom.home.cworth.org> (raw)
In-Reply-To: <1259830240-sup-2467@gopher.local>

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

On Thu, 03 Dec 2009 10:48:00 +0100, Marten Veldthuis <marten@veldthuis.com> wrote:
> I can see one clear case where that would become a problem: mistaggings.
> If I set up something so that in 99% of the cases, it'd tag new mail
> correctly with say "inbox unread mytag", I could quickly pick the
> mistagged ones out and remove the offending tag. 
> 
> If you do it like above however, the autotag script would come merrily
> along and retag them.

Right. A fully automatic, rule-based tag does not allow for manual
deletion of the exact same tag, (nor even manual addition).

I've given this some thought and there are things we could do here. For
example, the automatic tag could be stored internally under a different
prefix than the manual tag of the same name. That would be enough to
support the manual addition of a tag, such that a user-level search such
as:

	tag:foo

would map internally to something like:

	(auto-tag:foo OR manual-tag:foo)

Then manual tag removal could similarly be stored as yet anther internal
prefix that would work in a negative sense. So the search for "tag:foo"
would now map to:

	((auto-tag:foo OR manual-tag:foo) AND NOT manual-tag-removal:foo) [*]

I'm not sure yet if this idea is simply clever or insanely stupid.

It does seem like we could do this and hide all of the complexity
entirely from the user. But hidden complexity can raise its head in
nasty ways. Such as "I wrote this rule in my configuration file, why
isn't it working?" (in the face of a hidden manual-tag-removal).

Another idea would be to just keep the rule-based tags strictly as
configured, explicitly prevent the user from manually adding/removing
tags of the same name. And then the user could play games like the above
in saved searches to be able to simulate manual touchups of rule-based
tags, (without the automatic vs. manual state being hidden).

Yet another idea is to keep all rule-based tagging out of the
configuration, and let the user come up with whatever scheme they most
prefer. This could still allow for the configuration to hold saved
searches, (which could stand in for rule-based tags in a lot of cases
and avoid a lot of the complexity discussed here).

So those are some of my current thoughts on the issue. And that's why I
haven't put any auto tagging into the configuration file yet.

-Carl

[*] Or should that be:

	(manual-tag:foo OR (auto-tag:foo AND NOT manual-tag-removal:foo))

It probably wouldn't matter in practice as presumably the addition of
the manual-tag would remove any manual-tag-removal and vice-versa.

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

      reply	other threads:[~2009-12-04  6:18 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-24 22:10 [PATCH 0/4] Make tags applied by 'notmuch new' configurable Jan Janak
2009-11-24 22:10 ` [PATCH 1/4] notmuch-new: Remove tag_add_inbox_unread in favor of a generic solution Jan Janak
2009-11-24 22:10   ` [PATCH 2/4] notmuch: Config option to specify tags to be applied by 'notmuch new' Jan Janak
2009-11-24 22:10     ` [PATCH 3/4] notmuch-setup: Copy/create the new section with tags for 'notmuch-new' Jan Janak
2009-11-24 22:10       ` [PATCH 4/4] notmuch-new: New cmdline option --tag=<name> Jan Janak
2009-11-25  6:21         ` Karl Wiberg
2009-11-25 17:59           ` Jan Janak
2009-11-25 18:37         ` [PATCH] notmuch-new: Option to disable tags from the configuration file Jan Janak
2009-11-25 19:55           ` Bart Trojanowski
2009-11-25 21:25             ` Jan Janak
2009-11-25 20:56     ` [PATCH 2/4] notmuch: Config option to specify tags to be applied by 'notmuch new' Bart Trojanowski
2009-11-25 21:50       ` Jan Janak
2009-12-02 21:42         ` Carl Worth
2009-11-24 22:50 ` [PATCH 0/4] Make tags applied by 'notmuch new' configurable Brett Viren
2009-11-25  3:07 ` Bdale Garbee
2009-11-25  3:35 ` Bart Trojanowski
2009-11-25 23:30 ` [PATCH 1/5] notmuch-new: Remove tag_add_inbox_unread in favor of a generic solution Jan Janak
2009-11-25 23:30   ` [PATCH 2/5] notmuch: Config option to specify tags to be applied by 'notmuch new' Jan Janak
2009-11-25 23:30     ` [PATCH 3/5] notmuch-setup: Copy/create the new section with tags for 'notmuch-new' Jan Janak
2009-11-25 23:30       ` [PATCH 4/5] notmuch-new: New cmdline option --tag=<name> Jan Janak
2009-11-25 23:30         ` [PATCH 5/5] notmuch-new: Option to disable tags from the configuration file Jan Janak
2009-11-25 23:48 ` [PATCH 0/4] Make tags applied by 'notmuch new' configurable Jan Janak
2009-12-02 21:36 ` Carl Worth
2009-12-03  9:48   ` Marten Veldthuis
2009-12-04  6:17     ` Carl Worth [this message]

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=87r5rbfejz.fsf@yoom.home.cworth.org \
    --to=cworth@cworth.org \
    --cc=marten@veldthuis.com \
    --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).