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