Re: [notmuch] inbox/unread tags for new messages [was: Re: Thoughts on notmuch and...

[notmuch-archives.git] / 3a / bf93a3eb8cec506d6e7a830a76f1a9826a8db3

Return-Path: <jrollins@finestructure.net>\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 D8C9D431FBC\r
        for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 15:38:52 -0800 (PST)\r
X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
X-Spam-Flag: NO\r
X-Spam-Score: -2.59\r
X-Spam-Level: \r
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, \r
        BAYES_00=-2.599] autolearn=unavailable\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 gPuHRt+jp+k4 for <notmuch@notmuchmail.org>;\r
        Sat, 16 Jan 2010 15:38:52 -0800 (PST)\r
Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7])\r
        by olra.theworths.org (Postfix) with ESMTP id A4A92431FAE\r
        for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 15:38:52 -0800 (PST)\r
Received: from servo.finestructure.net (cpe-72-227-128-66.nyc.res.rr.com\r
        [72.227.128.66])\r
        (user=jgr2110 author=jrollins@finestructure.net mech=PLAIN bits=0)\r
        by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o0GNcfLc014173\r
        (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
        Sat, 16 Jan 2010 18:38:42 -0500 (EST)\r
Received: from jrollins by servo.finestructure.net with local (Exim 4.71)\r
        (envelope-from <jrollins@finestructure.net>)\r
        id 1NWIE4-0003oZ-PT; Sat, 16 Jan 2010 18:38:40 -0500\r
Date: Sat, 16 Jan 2010 18:38:40 -0500\r
From: Jameson Rollins <jrollins@finestructure.net>\r
To: Carl Worth <cworth@cworth.org>\r
Message-ID: <20100116233840.GA31869@finestructure.net>\r
References: <20100114084713.GA22273@harikalardiyari>\r
        <87eilse1hg.fsf@yoom.home.cworth.org>\r
        <20100115001600.GD25209@lapse.rw.madduck.net>\r
        <87vdf3cd1y.fsf@yoom.home.cworth.org>\r
        <20100115210934.GA12515@harikalardiyari>\r
        <87r5prc64e.fsf@yoom.home.cworth.org>\r
        <20100116201803.GA19570@finestructure.net>\r
        <87bpgtd71q.fsf@yoom.home.cworth.org>\r
MIME-Version: 1.0\r
Content-Type: multipart/signed; micalg=pgp-sha256;\r
        protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S"\r
Content-Disposition: inline\r
In-Reply-To: <87bpgtd71q.fsf@yoom.home.cworth.org>\r
User-Agent: Mutt/1.5.20 (2009-06-14)\r
X-No-Spam-Score: Local\r
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7\r
Cc: martin f krafft <madduck@madduck.net>, notmuch@notmuchmail.org\r
Subject: Re: [notmuch] inbox/unread tags for new messages [was: Re: Thoughts\r
 on notmuch and Lua]\r
X-BeenThere: notmuch@notmuchmail.org\r
X-Mailman-Version: 2.1.13\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: Sat, 16 Jan 2010 23:38:53 -0000\r
\r
\r
--AhhlLboLdkugWU4S\r
Content-Type: text/plain; charset=us-ascii\r
Content-Disposition: inline\r
Content-Transfer-Encoding: quoted-printable\r
\r
On Sat, Jan 16, 2010 at 02:22:09PM -0800, Carl Worth wrote:\r
> So the idea with "new" is really to just make the lower-level pieces of\r
> notmuch, (the command-line interface and the library), to steal less of\r
> the tag namespace. Specifically, the proposal is to reserve a single tag\r
> ("new") rather than two tags ("inbox" and "unread"). Then, it's a matter\r
> of some higher-level layers (such as the emacs interface) to apply\r
> special meaning to things like "inbox" and "unread".\r
\r
I personally don't really think that this is a good idea.  If this is\r
all left up to mail reader, and the mail readers all do something\r
different, then it would be very difficult to switch readers, or to\r
use different readers for different circumstances.  I really think\r
that all of this stuff should be handled uniformly by the notmuch CLI\r
in a very structured way.  If we make sane decisions at that level,\r
then things are nicely consistent.\r
\r
What I would instead suggest is that there is a notmuch new hook,\r
handled at the notmuch program level, that would allow users to define\r
scripts or functions that would be applied to all new messages.  Then\r
users could do whatever they want to new messages.  As long as it's\r
done at the notmuch CLI level, instead of at the reader level, things\r
won't get fractured by divergent reader implementations.  This ideal\r
is also in line with the proposal I put forth in\r
id:20100116204955.GA858@finestructure.net.\r
\r
> On Sat, 16 Jan 2010 15:18:03 -0500, Jameson Rollins <jrollins@finestructu=\r
re.net> wrote:=20\r
> > I think that the 'unread' tag should be tightly synced to the maildir\r
> > 'S' flags, which indicate the read status on the maildir message files\r
> > themselves.  This is useful for compatibility with other MUAs, and is\r
> > one of the few generally useful tags that can be synced through IMAP.\r
>=20\r
> The tight synchronization of this tag does seem useful. But I'm still\r
> not sure what the precise plan here should be. We could change from having\r
> the tag in the database be authoritative to instead have the character\r
> in the filename be authoritative, but we would need answers for the\r
> following questions:\r
>=20\r
>   1. How do we deal with files that don't match maildir conventions?\r
>      (Either not in a /cur or /new directory or not matching the\r
>      filename convention.)\r
\r
I'm not sure this is the right question.  It seems to me that if\r
notmuch is going to be using maildir, then notmuch itself should do\r
everything to conform to the maildir convention, as well as assume\r
that anything else touching the same maildirs is doing so as well.\r
Notmuch should be moving files from new to cur as it processes them,\r
and it should be adding the S flag if a message has been seen/read.\r
\r
If there are files in the maildir that don't conform, then they should\r
either be ignored with some sort of warning, or they should just be\r
added to the database with no special care at all (maybe with a\r
warning).\r
\r
>   2. How do we actually make the transition from the old scheme to the\r
>      new? (Perhaps we do this with an increment in the database version\r
>      number and transfer the data from the database to the filenames for\r
>      all known files at the time of the upgrade?)\r
\r
Is it really a scheme change that would require delicate handling?  I\r
would think that the change would be fairly straightforward:\r
\r
- if notmuch sees that a message in the maildir has moved from new to\r
  cur and/or the S flag has been added then any 'unread' flags should\r
  be removed from the message.\r
\r
- if a 'unread' tag is removed from a message, then the message S flag\r
  should be added.\r
\r
It doesn't seem that any database changes need to be made.\r
\r
> > The 'unread' tag should also not be something that the user ever\r
> > consciously has to get rid of.  Notmuch MUAs should just get rid of it\r
> > automatically when the user actually views the message.  The notmuch\r
> > emacs UI is currently not handling this very well, but I think we can\r
> > tweak that fairly easily.\r
>=20\r
> I agree on all points. I've been sitting on an unfinished patch series\r
> to implement some ideas I proposed here:\r
>=20\r
>       id:877ht3hfh0.fsf@yoom.home.cworth.org\r
>=20\r
> I plan to get back to finishing that soon. (I set all emacs interface\r
> work aside for a while to do the rename support.) Some of the ideas I\r
> outline there will make the handling of unread more sane I think. I'd be\r
> glad to hear any further ideas.\r
\r
I really think this should just be done in the most stupid simple way\r
imaginable: if you view/open a message buffer, the 'unread' tag goes\r
away.  That simple.  I really don't think it's worth spending any time\r
trying to make it more nuanced or sophisticated than that.  Users\r
should not ever have to think about changing this tag, and if they\r
really want to, they can just use the tag function.\r
\r
> I totally agree. One of the most-important reasons I had in mind when\r
> starting notmuch was the desired to get to a point where I could\r
> actually reason about, and explore more-improved mail flow. Everything\r
> so far has been about getting some low-level plumbing working. I've got\r
> a bunch of ideas for novel mail-handling techniques that will be enabled\r
> by notmuch, and we definitely haven't scratched the surface yet. I'm\r
> sure many readers of this list have similar (and different!) ideas and\r
> I'm looking forward to seeing what we can come up with together.\r
\r
Yeah, I am totally on board with your vision for notmuch, Carl.  It's\r
a incredibly nice new way to handle mail.  You've done a great job\r
keeping things simple yet flexible.  I really hope we can continue in\r
that same vein.  I think that the proposal I put forward in my other\r
message will help further that goal (keep things simple and well\r
structured, but allow flexibility).\r
\r
I have no doubt that there will be lots of very novel uses for notmuch\r
in the future.  I was already talking to a friend about how notmuch\r
should absolutely be used by mailing list handlers.  How sweet would\r
it be to have web interfaces to notmuch mail list archives.\r
\r
jamie.\r
\r
--AhhlLboLdkugWU4S\r
Content-Type: application/pgp-signature; name="signature.asc"\r
Content-Description: Digital signature\r
Content-Disposition: attachment\r
\r
-----BEGIN PGP SIGNATURE-----\r
Version: GnuPG v1.4.10 (GNU/Linux)\r
\r
iQIcBAEBCAAGBQJLUk35AAoJEO00zqvie6q8YzEQAJR9CAGUk8zClqNcFyqlDbRS\r
6ln5lcV2GniB/twbUYZL2E1mFyv+YHe3k44XmuWKne0Dh4Q1mwri5HJyk8/m8fYr\r
EHGYgf1CmZgb1bbqP2X0gxBbpnJIU9MJOnGnOx+easipkKnDRBJyBSNuuSxcbJ08\r
ISB4IBy5XzMwa0G+Rxt2bTDixY20XsLeIKQcR9ueD3yQSJ5m7LFTjO0CbIf6BGwA\r
AonLwwEPcxHqyQeGnoTLMU8bK6A+0pf92ALaHJzG7QkXNYtmYChOkFo3KllEEIRb\r
w+LjxsPNrhql+Yx8ZrqdwQ24Bc2f5myjQ7Ms+IP2TYa6Rq0ARJ2oexe2UfMlWlYX\r
wVPnsmml2nKWRUP55XiAETFo5eHP57vmIEWt0f5da0wdxkCCbEc5SqsSrPg8YNyJ\r
E71FAcQtTbbd8NLijfD2i/sBqNQOR9z6A4Ek+WTLSlqgfsTOHUd+p5ArTrN2jQgd\r
bOG7WuhrOf/8gxQgZTIgGMyO5hqPrCVuGIfNr06sqV6djJ8dmE+MXOxcgb7RwYVb\r
Uwmgcx/AltsAI85qZ6OhhdwXyv7aHMW8FPtYvh/6GZZRn9MJQ3JLlXDk5iJrs47m\r
nF61QjQ/YF0UBodX0QWPlGk0B7iJacSvajU67o7yofwhTBNdn6REd3aAVqAnw43v\r
ABHPPtmGUM+sCZApIi4K\r
=K8aT\r
-----END PGP SIGNATURE-----\r
\r
--AhhlLboLdkugWU4S--\r