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 49E46431FBF;
\r
6 Sun, 22 Nov 2009 22:06:24 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
8 Received: from olra.theworths.org ([127.0.0.1])
\r
9 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
10 with ESMTP id zB0QjTR929lT; Sun, 22 Nov 2009 22:06:23 -0800 (PST)
\r
11 Received: from cworth.org (localhost [127.0.0.1])
\r
12 by olra.theworths.org (Postfix) with ESMTP id 147CE431FAE;
\r
13 Sun, 22 Nov 2009 22:06:23 -0800 (PST)
\r
14 From: Carl Worth <cworth@cworth.org>
\r
15 To: Keith Packard <keithp@keithp.com>, notmuch@notmuchmail.org
\r
16 In-Reply-To: <yun7htkcou6.fsf@aiko.keithp.com>
\r
17 References: <yun7htkcou6.fsf@aiko.keithp.com>
\r
18 Date: Mon, 23 Nov 2009 07:06:06 +0100
\r
19 Message-ID: <87639122sx.fsf@yoom.home.cworth.org>
\r
21 Content-Type: text/plain; charset=us-ascii
\r
22 Subject: Re: [notmuch] notmuch 'index' mode.
\r
23 X-BeenThere: notmuch@notmuchmail.org
\r
24 X-Mailman-Version: 2.1.12
\r
26 List-Id: "Use and development of the notmuch mail system."
\r
27 <notmuch.notmuchmail.org>
\r
28 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
29 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
30 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
31 List-Post: <mailto:notmuch@notmuchmail.org>
\r
32 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
33 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
34 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
35 X-List-Received-Date: Mon, 23 Nov 2009 06:06:24 -0000
\r
37 On Fri, 20 Nov 2009 23:35:29 -0800, Keith Packard <keithp@keithp.com> wrote:
\r
38 > I posted a patch adding an 'index' mode to notmuch and though I'd
\r
39 > explain my idea. Most mail systems provide a 'folder view' mode which
\r
40 > displays the set of folders and a count of messages in each folder. I
\r
41 > used this myself as the first sort of which messages I want to read.
\r
43 I've just pushed this set of patches out now.
\r
45 I like it quite a bit. Here are some thoughts:
\r
47 * The mode documentation really needs to walk the user through how to
\r
48 setup a custom set of folders.
\r
50 * It's not opening my "to-me" folder for some reason. (I thought it
\r
51 was the '-' at first, but "xorg-board" is working fine). I can debug
\r
54 * The presentation is impressively spartan[*]. :-)
\r
56 If we spruce this up a bit, I think we'll want to make this the default
\r
57 view of "M-x notmuch".
\r
59 Oh, and instead of just documenting how to set a variable in .emacs we
\r
60 should just provide commands to add/remove folders.
\r
62 > One missing piece here is that the searches don't have a
\r
63 > total/unread count. Because the 'notmuch count' command is so fast
\r
64 > (notmuch count the returns 532891 on my machine, and takes 0.240
\r
65 > seconds), we really could count the number of messages matching a single
\r
66 > tag and then *also* count the number of messages matching that tag and
\r
69 I think the number of threads matching the search is the only
\r
70 interesting number actually. Otherwise, you just end up printing a bunch
\r
71 of big numbers that the user doesn't need for anything.
\r
73 > Another missing piece is that these should be shared with the
\r
74 > notmuch-poll script, probably via the .notmuch-config file. I do like
\r
75 > that I can have some entries here that aren't in my notmuch-poll script.
\r
77 Yes, once we add configuration for automated tagging, we'll want to
\r
78 figure out how to include those here. I'm not sure if they should just
\r
79 be an initial default that the user tweaks, or if any configured rules
\r
80 from that file should always be presented until the user explicitly asks
\r
81 for one to be ignored (think about a "spam" tag). So that might take
\r
82 some experimentation.
\r
84 You're definitely right that we want to support searches other than
\r
85 simply the tag names in the configuration file. For example, here's the
\r
86 search I'm currently using for the "notmuch" folder (so I can process
\r
87 outstanding patches in order):
\r
89 tag:notmuch and (tag:inbox or tag:todo)
\r
91 Though, really, I probably wouldn't mind using a search string like that
\r
92 for any of my automated tags. It's equivalent to what you were doing if
\r
93 there are no "todo" tags on messages with the tag of interest, and then
\r
94 as soon as there are any "todo" tags on any of those messages, then I
\r
95 probably do want them in that folder.
\r
97 So maybe the user configures a search template to use for each automatic
\r
100 > It might be nice to make this hierarchical as I used to do with
\r
101 > evolution's vfolder stuff -- an 'intel' folder with an 'intel/unread'
\r
102 > sub-folder. That would be done with simple conjunctions of tags, but
\r
103 > providing some structure on the screen might be nice.
\r
105 > I'm also wondering if we should elide, or at least change the appearance,
\r
106 > of lines which match zero messages.
\r
110 > I'd also like to be able to get the system to display my mail in three
\r
111 > panes -- one with the index, one with the current search and the last
\r
112 > with the current thread. Getting those laid out on the screen correctly
\r
113 > and letting you get them back to that layout easily would make notmuch
\r
114 > look a lot more like other email clients, a form I've found fairly
\r
115 > functional as I do not generally read mail in a linear fashion.
\r
117 Yes. Emacs has pretty good support for saving and restoring an entire
\r
118 window configuration, so we should be able to make this work.
\r
120 And by the way, lest you be misled by the "magic space bar", I don't
\r
121 read my mail very linearly either. I always filter by at least one tag
\r
122 first and I want to prioritize which one. The folder mode is great for
\r
123 this. It's only when I get my search results down below a particular
\r
124 threshold that I decide I want to read everything linearly.
\r
126 (And if I can't get a particular folder down that small, then I'll do
\r
127 selective reading (with 'x', yes, I think we're agreeing on that now),
\r
128 and then archive away the lot.)
\r
130 Anyway, thanks for the great addition to notmuch.
\r
134 [*] A nice thing about this is it give us plenty of room to have a
\r
135 paragraph or two explaining how notmuch works, what the user can expect,
\r
136 what keys to use, etc.
\r
projects / notmuch-archives.git / blob