1 Return-Path: <cworth@cworth.org>
\r
2 X-Original-To: notmuch@notmuchmail.org
\r
3 Delivered-To: notmuch@notmuchmail.org
\r
4 Received: from localhost (localhost [127.0.0.1])
\r
5 by olra.theworths.org (Postfix) with ESMTP id CC0EE431FBC
\r
6 for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 14:22:14 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5
\r
12 tests=[ALL_TRUSTED=-1.8, AWL=1.261, BAYES_00=-2.599] autolearn=ham
\r
13 Received: from olra.theworths.org ([127.0.0.1])
\r
14 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
15 with ESMTP id BhBTACE2egs1; Sat, 16 Jan 2010 14:22:13 -0800 (PST)
\r
16 Received: from yoom.home.cworth.org (localhost [127.0.0.1])
\r
17 by olra.theworths.org (Postfix) with ESMTP id 84E6A431FAE;
\r
18 Sat, 16 Jan 2010 14:22:12 -0800 (PST)
\r
19 Received: by yoom.home.cworth.org (Postfix, from userid 1000)
\r
20 id 3A525550090; Sat, 16 Jan 2010 14:22:10 -0800 (PST)
\r
21 From: Carl Worth <cworth@cworth.org>
\r
22 To: Jameson Rollins <jrollins@finestructure.net>
\r
23 In-Reply-To: <20100116201803.GA19570@finestructure.net>
\r
24 References: <20100114084713.GA22273@harikalardiyari>
\r
25 <87eilse1hg.fsf@yoom.home.cworth.org>
\r
26 <20100115001600.GD25209@lapse.rw.madduck.net>
\r
27 <87vdf3cd1y.fsf@yoom.home.cworth.org>
\r
28 <20100115210934.GA12515@harikalardiyari>
\r
29 <87r5prc64e.fsf@yoom.home.cworth.org>
\r
30 <20100116201803.GA19570@finestructure.net>
\r
31 Date: Sat, 16 Jan 2010 14:22:09 -0800
\r
32 Message-ID: <87bpgtd71q.fsf@yoom.home.cworth.org>
\r
34 Content-Type: multipart/signed; boundary="=-=-=";
\r
35 micalg=pgp-sha1; protocol="application/pgp-signature"
\r
36 Cc: martin f krafft <madduck@madduck.net>, notmuch@notmuchmail.org
\r
37 Subject: Re: [notmuch] inbox/unread tags for new messages [was: Re: Thoughts
\r
39 X-BeenThere: notmuch@notmuchmail.org
\r
40 X-Mailman-Version: 2.1.13
\r
42 List-Id: "Use and development of the notmuch mail system."
\r
43 <notmuch.notmuchmail.org>
\r
44 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
45 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
46 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
47 List-Post: <mailto:notmuch@notmuchmail.org>
\r
48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
49 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
50 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
51 X-List-Received-Date: Sat, 16 Jan 2010 22:22:15 -0000
\r
55 On Sat, 16 Jan 2010 15:18:03 -0500, Jameson Rollins <jrollins@finestructure.net> wrote:
\r
56 > Hey, Carl. I would actually like to argue against replacing the
\r
57 > 'inbox' and 'unread' tags with a single "new" tag. Here's why:
\r
59 Oh, well maybe I didn't make that very clear.
\r
61 Personally, the only thing *I* would do with a "new" tag would be to
\r
62 have my auto-tagger search for anything tagged as "new" and tag that as
\r
63 "inbox" and "unread".
\r
65 I definitely agree that it's important to separate these two
\r
66 notions. And as you refer to below, the emacs UI makes plenty of
\r
67 assumptions about these tags existing and manipulating them on behalf of
\r
70 So the idea with "new" is really to just make the lower-level pieces of
\r
71 notmuch, (the command-line interface and the library), to steal less of
\r
72 the tag namespace. Specifically, the proposal is to reserve a single tag
\r
73 ("new") rather than two tags ("inbox" and "unread"). Then, it's a matter
\r
74 of some higher-level layers (such as the emacs interface) to apply
\r
75 special meaning to things like "inbox" and "unread".
\r
77 > At first I didn't think I liked the fact that new messages were doubly
\r
78 > tagged with 'inbox' and 'unread'. But then I realized that what I was
\r
79 > really not liking was the way that the emacs UI was handling those
\r
80 > tags, and the more I thought about it I realized that those two tags
\r
81 > are very useful and we just need to streamline how they're handled.
\r
83 I agree some changes are needed.
\r
85 > I think that the 'unread' tag should be tightly synced to the maildir
\r
86 > 'S' flags, which indicate the read status on the maildir message files
\r
87 > themselves. This is useful for compatibility with other MUAs, and is
\r
88 > one of the few generally useful tags that can be synced through IMAP.
\r
90 The tight synchronization of this tag does seem useful. But I'm still
\r
91 not sure what the precise plan here should be. We could change from having
\r
92 the tag in the database be authoritative to instead have the character
\r
93 in the filename be authoritative, but we would need answers for the
\r
94 following questions:
\r
96 1. How do we deal with files that don't match maildir conventions?
\r
97 (Either not in a /cur or /new directory or not matching the
\r
98 filename convention.)
\r
100 2. How do we actually make the transition from the old scheme to the
\r
101 new? (Perhaps we do this with an increment in the database version
\r
102 number and transfer the data from the database to the filenames for
\r
103 all known files at the time of the upgrade?)
\r
105 > The 'unread' tag should also not be something that the user ever
\r
106 > consciously has to get rid of. Notmuch MUAs should just get rid of it
\r
107 > automatically when the user actually views the message. The notmuch
\r
108 > emacs UI is currently not handling this very well, but I think we can
\r
109 > tweak that fairly easily.
\r
111 I agree on all points. I've been sitting on an unfinished patch series
\r
112 to implement some ideas I proposed here:
\r
114 id:877ht3hfh0.fsf@yoom.home.cworth.org
\r
116 I plan to get back to finishing that soon. (I set all emacs interface
\r
117 work aside for a while to do the rename support.) Some of the ideas I
\r
118 outline there will make the handling of unread more sane I think. I'd be
\r
119 glad to hear any further ideas.
\r
121 > As for the 'inbox' tag, I think it should be kept because it has a
\r
122 > very particular, well understood, and useful semantic meaning for MUAs
\r
123 > that people already understand. My mail inbox is actually what I'm
\r
124 > syncing via offlineimap and I would like the 'inbox' tag to correspond
\r
125 > directly to the messages that are in my actual maildir inbox.
\r
127 Yes. If we change to "unread" simply being state that is controlled
\r
128 entirely by the mailstore, then we would be to the point where "inbox"
\r
129 is the only tag being claimed from the tag namespace by "notmuch
\r
130 new". And at that point, I agree we could/should just leave it named
\r
131 "inbox" rather than "new".
\r
133 > This last point I think is very important because I think it
\r
134 > corresponds to the way that *most* people are or need to handle their
\r
135 > mail, and it's something that I think notmuch hasn't quite fully come
\r
136 > to grips with yet.
\r
138 I totally agree. One of the most-important reasons I had in mind when
\r
139 starting notmuch was the desired to get to a point where I could
\r
140 actually reason about, and explore more-improved mail flow. Everything
\r
141 so far has been about getting some low-level plumbing working. I've got
\r
142 a bunch of ideas for novel mail-handling techniques that will be enabled
\r
143 by notmuch, and we definitely haven't scratched the surface yet. I'm
\r
144 sure many readers of this list have similar (and different!) ideas and
\r
145 I'm looking forward to seeing what we can come up with together.
\r
147 > I'm going to follow up this message with another one that describes my
\r
148 > idea for a streamlined message flow in notmuch that would utilize
\r
149 > these tags better.
\r
151 I'll look forward to that. Thanks again!
\r
156 Content-Type: application/pgp-signature
\r
158 -----BEGIN PGP SIGNATURE-----
\r
159 Version: GnuPG v1.4.10 (GNU/Linux)
\r
161 iD8DBQFLUjwS6JDdNq8qSWgRAggIAJ9Ok/eBGWKkCPjNGDObzYEof5c9yQCfQeF6
\r
162 rLlhBJnXs8X3nZ8Mvolr8Rc=
\r
164 -----END PGP SIGNATURE-----
\r
projects / notmuch-archives.git / blob