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 CC0EE431FBC for ; Sat, 16 Jan 2010 14:22:14 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.8, AWL=1.261, BAYES_00=-2.599] autolearn=ham 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 BhBTACE2egs1; Sat, 16 Jan 2010 14:22:13 -0800 (PST) Received: from yoom.home.cworth.org (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 84E6A431FAE; Sat, 16 Jan 2010 14:22:12 -0800 (PST) Received: by yoom.home.cworth.org (Postfix, from userid 1000) id 3A525550090; Sat, 16 Jan 2010 14:22:10 -0800 (PST) From: Carl Worth To: Jameson Rollins In-Reply-To: <20100116201803.GA19570@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> Date: Sat, 16 Jan 2010 14:22:09 -0800 Message-ID: <87bpgtd71q.fsf@yoom.home.cworth.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" 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 22:22:15 -0000 --=-=-= On Sat, 16 Jan 2010 15:18:03 -0500, Jameson Rollins wrote: > Hey, Carl. I would actually like to argue against replacing the > 'inbox' and 'unread' tags with a single "new" tag. Here's why: Oh, well maybe I didn't make that very clear. Personally, the only thing *I* would do with a "new" tag would be to have my auto-tagger search for anything tagged as "new" and tag that as "inbox" and "unread". I definitely agree that it's important to separate these two notions. And as you refer to below, the emacs UI makes plenty of assumptions about these tags existing and manipulating them on behalf of the user. 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". > At first I didn't think I liked the fact that new messages were doubly > tagged with 'inbox' and 'unread'. But then I realized that what I was > really not liking was the way that the emacs UI was handling those > tags, and the more I thought about it I realized that those two tags > are very useful and we just need to streamline how they're handled. I agree some changes are needed. > 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. 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: 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.) 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?) > 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. I agree on all points. I've been sitting on an unfinished patch series to implement some ideas I proposed here: id:877ht3hfh0.fsf@yoom.home.cworth.org 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. > As for the 'inbox' tag, I think it should be kept because it has a > very particular, well understood, and useful semantic meaning for MUAs > that people already understand. My mail inbox is actually what I'm > syncing via offlineimap and I would like the 'inbox' tag to correspond > directly to the messages that are in my actual maildir inbox. Yes. If we change to "unread" simply being state that is controlled entirely by the mailstore, then we would be to the point where "inbox" is the only tag being claimed from the tag namespace by "notmuch new". And at that point, I agree we could/should just leave it named "inbox" rather than "new". > This last point I think is very important because I think it > corresponds to the way that *most* people are or need to handle their > mail, and it's something that I think notmuch hasn't quite fully come > to grips with yet. 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. > I'm going to follow up this message with another one that describes my > idea for a streamlined message flow in notmuch that would utilize > these tags better. I'll look forward to that. Thanks again! -Carl --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLUjwS6JDdNq8qSWgRAggIAJ9Ok/eBGWKkCPjNGDObzYEof5c9yQCfQeF6 rLlhBJnXs8X3nZ8Mvolr8Rc= =y9uu -----END PGP SIGNATURE----- --=-=-=--