database error

[notmuch-archives.git] / b4 / 574552ff601618efd2ec7fe48368412af2e762

Return-Path: <cworth@cworth.org>\r
X-Original-To: notmuch@notmuchmail.org\r
Delivered-To: notmuch@notmuchmail.org\r
Received: from localhost (localhost [127.0.0.1])\r
        by olra.theworths.org (Postfix) with ESMTP id AC360431FC0;\r
        Wed,  2 Dec 2009 13:36:15 -0800 (PST)\r
X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
Received: from olra.theworths.org ([127.0.0.1])\r
        by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
        with ESMTP id ApUQpouN4CKZ; Wed,  2 Dec 2009 13:36:14 -0800 (PST)\r
Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
        by olra.theworths.org (Postfix) with ESMTP id 4052B431FAE;\r
        Wed,  2 Dec 2009 13:36:14 -0800 (PST)\r
Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
        id F11D82542A9; Wed,  2 Dec 2009 13:36:13 -0800 (PST)\r
From: Carl Worth <cworth@cworth.org>\r
To: Jan Janak <jan@ryngle.com>, notmuch@notmuchmail.org\r
In-Reply-To: <1259100630-13673-1-git-send-email-jan@ryngle.com>\r
References: <1259100630-13673-1-git-send-email-jan@ryngle.com>\r
Date: Wed, 02 Dec 2009 13:36:13 -0800\r
Message-ID: <87ws1583ea.fsf@yoom.home.cworth.org>\r
MIME-Version: 1.0\r
Content-Type: multipart/signed; boundary="=-=-=";\r
        micalg=pgp-sha1; protocol="application/pgp-signature"\r
Subject: Re: [notmuch] [PATCH 0/4] Make tags applied by 'notmuch new'\r
 configurable.\r
X-BeenThere: notmuch@notmuchmail.org\r
X-Mailman-Version: 2.1.12\r
Precedence: list\r
List-Id: "Use and development of the notmuch mail system."\r
        <notmuch.notmuchmail.org>\r
List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
        <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
List-Post: <mailto:notmuch@notmuchmail.org>\r
List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
        <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
X-List-Received-Date: Wed, 02 Dec 2009 21:36:15 -0000\r
\r
--=-=-=\r
Content-Transfer-Encoding: quoted-printable\r
\r
On Tue, 24 Nov 2009 23:10:26 +0100, Jan Janak <jan@ryngle.com> wrote:\r
> I would like to propose that we make the list of tags applied by 'notmuch=\r
 new'\r
> configurable. Right now notmuch applies two tags to all new messages adde=\r
d to\r
> the database, 'inbox' and 'unread'. The two tags are added by the C code =\r
in\r
> notmuch-new.c and they cannot be changed without editing the source file =\r
and\r
> recompiling notmuch.\r
\r
Hi Jan,\r
\r
Sorry to leave this thread sitting without review for so long. My travel\r
schedule, combined with a big US holiday last week combined to create a\r
fair amount of backlog.\r
\r
> This change was motivated by my desire to remove both tags from newly add=\r
ed\r
> messages. My rules for adding these two tags are more complex and I do it=\r
 in\r
> a script run after 'notmuch new'. Instead of 'inbox' and 'unread', I conf=\r
igure\r
> 'notmuch new' to add a new tag called 'new' (and only that one). This tag\r
> marks newly added messages that haven't been properly tagged yet by my=20\r
> auto-tagging scripts. The last script I run after 'notmuch new' removes t=\r
hat\r
> tag. My auto-tagging scripts process only messages with the tag 'new'.\r
\r
As a side-note, I would recommend against making your auto-tagging\r
scripts process only new messages. You can get a much more reliable\r
setup by having your auto-tagging scripts apply to the global\r
database. And this is not inefficient at all if you simply ensure that\r
you only match messages which need the tag added.\r
\r
For example, in your current setup you presumably have something like:\r
\r
        notmuch tag +foo <foo-specific-search-terms> and tag:new\r
\r
If you change that to:\r
\r
        notmuch tag +foo <foo-specific-search-terms> and not tag:foo\r
\r
then you have the advantage of being able to change the search terms you\r
are using for the "foo" tag and know that this tag will be applied\r
globally, (and not only to messages incorporated since the rule\r
change). Also, you should find that this performs just fine.\r
\r
You could also have a second specification that would support removing\r
the "foo" tag if the terms ever changed to become more restrictive:\r
\r
        notmuch tag -foo tag:foo and not (<foo-specific-search-terms)\r
\r
I've talked about doing "virtual tags" in the configuration file which\r
would implement basically the logic of these two "notmuch tag" commands\r
and be configured by simply providing the pair of:\r
\r
        "foo" and <foo-specific-search-terms>\r
\r
So, that's a slightly-off-topic recommendation for doing global tagging\r
rather than tagging based on new messages only. (Sup's support for\r
automatic tagging is only for new messages, and I learned there how\r
painful it can be to operate like that.)\r
\r
OK, that was a rather long side-note.\r
\r
Back to the patch, I do recognize that having "inbox" and "unread"\r
hard-coded within "notmuch new" is rather strict. So I'm definitely\r
interested in allowing something more flexible here. And I think the\r
configuration syntax you came up with makes a lot of sense for that.\r
\r
> On a side note; It may seem logical to add/omit the tag 'unread' directly=\r
 in=20\r
> 'notmuch new' based on the Maildir flags extracted from the filename of t=\r
he\r
> message. I suggest that we don't do that in 'notmuch new'. A better way w=\r
ould\r
> be writing a small script or command that can be run *after* 'notmuch new=\r
'.\r
> We could then distribute it with notmuch (maybe with other small tagging\r
> scripts for common situations).=20\r
\r
I do appreciate the sentiment here, (provide good support for\r
scriptability and let the user use that for extended functionality). But\r
the question is, how far do we take that idea? For example, we could\r
simply hard-code a single "new" tag and say that anyone that wants\r
"inbox" and "unread" on new messages should do:\r
\r
        notmuch tag +inbox +unread -new tag:new\r
\r
Would that make notmuch a more elegant system, or would it just be\r
harder to use than just allowing the inbox and unread tags in the\r
configuration file?\r
\r
> I think Maildir flags should be processed after 'notmuch new' is because =\r
if\r
> there are multiple copies of a message with different flags, we may need =\r
to\r
> see all flags from all filenames to set corresponding tags properly and w=\r
e may\r
> also need to take the directory part into consideration (i.e. the new mai=\r
l is\r
> in 'new', not 'cur').\r
\r
I think we're going to have to solve all of these problems anyway. We've\r
already got outstanding patches for dealing with message renames. And\r
the message rename case is identical to the case of duplicate messages\r
with different tags, (differing only in whether both filenames are still\r
present in the mail store).\r
\r
> There is one catch for users who already have a configuration file and st=\r
art\r
> using the patches. They will need to add the new section and the tags opt=\r
ion\r
> manually if they want to preserve current behavior of applying 'inbox' and\r
> 'unread' automatically by 'notmuch new'.\r
\r
Why not support backwards compatibility by simply treating an empty\r
configuration value as "inbox;unread"? We could even make the\r
notmuch-config code notice a case like this and write out the new\r
configuration file with the new option explicitly in it, (with\r
documentation).\r
\r
I'd definitely like to see a smooth upgrade path where existing users\r
get as much benefit from a complete and well-documented configuration\r
file as new users. (I've been frustrated by too many programs where the\r
only way to get a well-documented configuration is to start from\r
scratch.)\r
\r
> The last patch in the set adds a new command line option to 'notmuch new'.\r
> The name of the option is --tag and it can be used to override any tags\r
> configured in the configuration file. For example:\r
>=20\r
>   notmuch new --tag=3Doutbox --tag=3Dread\r
>=20\r
> adds the tags 'outbox' and 'read' and ignores any tags from the configura=\r
tion\r
> file.\r
\r
I don't like the idea of adding command-line-based tags to "notmuch\r
new", at least the way "notmuch new" currently works, (searching through\r
a mail store for any new files).\r
\r
In the actual patch, you identified a use-case for this that is\r
important, (importing a new collection of messages and wanting them all\r
tagged together). The problem of doing this with the existing "notmuch\r
new" is that it's too easy to accidentally tag more than is\r
intended. The only way to make it work would be to:\r
\r
        1. Turn off anything delivering mail to the mailstore\r
\r
        2. Ensure that the delivery is actually complete somehow, (and\r
           not still pending in local MTA queues, etc.)\r
\r
        3. Run "notmuch new" to ensure all recently-delivered mail is\r
           incorporated.\r
\r
        4. Copy the new collection of mail into the mail store.\r
\r
        5. Run "notmuch new --tag" with the collection-specific tag.\r
\r
        6. Turn on mail delivery again.\r
\r
That's too hard, and far too error-prone. (I don't know of any good way\r
to do step (2) on my system, for example.)\r
\r
If we had something like "notmuch import" that took files (perhaps even\r
an mbox) and copied them into the mail store, then *that* command could\r
legitimately accept a --tag option.\r
\r
Meanwhile, the way I think I'd like to see this operation supported is\r
by a search specification that operates on the filenames. People have\r
already asked for support for doing tagging based on directory names,\r
(which will apparently allow people to keep their collection of\r
Gmail-created tags). So I'd like to see something like this instead for\r
the use case:\r
\r
        mv some-archive ~/mail-store/some-archive\r
        notmuch tag +some-archive filename:some-archive*\r
\r
This idea seems very much in line with what you advocated earlier,\r
(handling the maildir "unread" flag after the fact, rather than in\r
"notmuch new").\r
\r
And yes, I realize that I'm arguing on different sides of the issue\r
here. Trying to decide how much "notmuch new" should or shouldn't do is\r
a tricky thing, and I'm hoping that by arguing from both sides I'll\r
better be able to see the right answer. :-)\r
\r
=2DCarl\r
\r
--=-=-=\r
Content-Type: application/pgp-signature\r
\r
-----BEGIN PGP SIGNATURE-----\r
Version: GnuPG v1.4.10 (GNU/Linux)\r
\r
iD8DBQFLFt3N6JDdNq8qSWgRAkMqAJ41y78dTqfm4dackN8I5BB7dsFXnwCgpkaA\r
m/Wztq3l9qY8UK2ND1cd0fE=\r
=frFh\r
-----END PGP SIGNATURE-----\r
--=-=-=--\r