Re: Hi all
[notmuch-archives.git] / 67 / 0e62b1380f4d7223659aba1a7164bfcf1b56af
1 Return-Path: <gregor@sam.mediasupervision.de>\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 CC4DC431FBC\r
6         for <notmuch@notmuchmail.org>; Thu,  3 Dec 2009 05:33:58 -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 Mz+HPAq6+Nbg for <notmuch@notmuchmail.org>;\r
11         Thu,  3 Dec 2009 05:33:58 -0800 (PST)\r
12 Received: from mout.perfora.net (mout.perfora.net [74.208.4.195])\r
13         by olra.theworths.org (Postfix) with ESMTP id 1429D431FAE\r
14         for <notmuch@notmuchmail.org>; Thu,  3 Dec 2009 05:33:58 -0800 (PST)\r
15 Received: from sam.mediasupervision.de ([80.152.3.104])\r
16         by mx.perfora.net (node=mxus2) with ESMTP (Nemesis)\r
17         id 0MCbPO-1NOP1k4A4Y-009o5k for notmuch@notmuchmail.org;\r
18         Thu, 03 Dec 2009 08:33:55 -0500\r
19 Received: from localhost (sam.mediasupervision.de [127.0.0.1])\r
20         by sam.mediasupervision.de (Postfix) with ESMTP id 0696A485C5F\r
21         for <notmuch@notmuchmail.org>; Thu,  3 Dec 2009 14:33:52 +0100 (CET)\r
22 X-Virus-Scanned: Debian amavisd-new at sam.mediasupervision.de\r
23 Received: from sam.mediasupervision.de ([127.0.0.1])\r
24         by localhost (sam.mediasupervision.de [127.0.0.1]) (amavisd-new,\r
25         port 10024) with ESMTP id r27VZKhbpfEW for <notmuch@notmuchmail.org>;\r
26         Thu,  3 Dec 2009 14:33:51 +0100 (CET)\r
27 Received: by sam.mediasupervision.de (Postfix, from userid 1000)\r
28         id D88CA485C6B; Thu,  3 Dec 2009 14:33:51 +0100 (CET)\r
29 Content-Type: text/plain; charset=UTF-8\r
30 From: Gregor Hoffleit <gregor@hoffleit.de>\r
31 To: notmuch <notmuch@notmuchmail.org>\r
32 Date: Thu, 03 Dec 2009 14:33:51 +0100\r
33 Message-Id: <1259840063-sup-1478@sam.mediasupervision.de>\r
34 User-Agent: Sup/git\r
35 Content-Transfer-Encoding: 8bit\r
36 Subject: [notmuch] Notmuch's search view sucks\r
37 X-BeenThere: notmuch@notmuchmail.org\r
38 X-Mailman-Version: 2.1.12\r
39 Precedence: list\r
40 List-Id: "Use and development of the notmuch mail system."\r
41         <notmuch.notmuchmail.org>\r
42 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
43         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
44 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
45 List-Post: <mailto:notmuch@notmuchmail.org>\r
46 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
47 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
48         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
49 X-List-Received-Date: Thu, 03 Dec 2009 13:33:59 -0000\r
50 \r
51 Hi there,\r
52 \r
53 first a short introduction: I was a mutt user for ages. When I read\r
54 about Sup, I was intrigued. After a short evaluation period, I switched\r
55 to Sup, which I'm now using since six months. \r
56 \r
57 Sup has many rough edges on its own, and it's not that easy to fix some\r
58 of them from the current codebase. notmuch looks like a clean restart of\r
59 the same idea, but with a different architecture. I like the concept of\r
60 a command line tool with a minimal set of functionality as a common\r
61 core, upon which different clients can build on.\r
62 \r
63 \r
64 But. Compared to Sup, the current notmuch clients suck :-)\r
65 \r
66 \r
67 Today: Sup's search-results-mode. It has a lot of polish that's plainly\r
68 missing from notmuch.el (or notmuch.vim):\r
69 \r
70 - Sup's display is much terse than notmuch, still\r
71 - Sup manages to display the first few words of the first unread message\r
72   in the thread.\r
73 - If a thread contains many authors, Sup shows only the firstnames.\r
74   If that's still too long to fit, it cuts off at some point.\r
75 - User's name is rewritten as 'me'.\r
76 - The message date format needs only 8 characters (notmuch: 12).\r
77 - Message count is only displayed when necessary (>=1).\r
78 - Threads with unread messages are bold (resp. hilighted).\r
79 - Threads with attachments are marked with an "@".\r
80 - Threads with mails to user are marked with an ">".\r
81 - Different colors of tags, message content.\r
82 \r
83 All in all, 'notmuch search' is a raw representation of field values,\r
84 while Sup's search-results-mode shows a polished and terse\r
85 interpretation of the same values, for human beings, even optimized for\r
86 the current display width.\r
87 \r
88 Now notmuch.el and notmuch.vim just display the output of 'notmuch\r
89 search', verbatim (perhaps enhanced with coloring based on regexes).\r
90 \r
91 \r
92 I'm experimenting with a notmuch web client (currently 'evenless'),\r
93 trying to replicate much of the feeling of Sup, in a web client.\r
94 \r
95 First, I took the output of 'notmuch search', parsed it and tried to\r
96 reformat it like Sup. That worked well for all fields but the date\r
97 field: In contrast to the other fields, notmuch's date representation\r
98 is intended for direct consumption by humans (english-speaking, that is\r
99 ;-).\r
100 \r
101 \r
102 I noticed this entry in TODO:\r
103 \r
104     Add a "--format" option to "notmuch search", (something printf-like\r
105     for selecting what gets printed).\r
106 \r
107 Since I'm not eager to write a format parser, I started to implement\r
108 --format as an enumerating option notmuch_format_t. By now, I have\r
109 NOTMUCH_FORMAT_DEFAULT and NOTMUCH_FORMAT_SUP. do_search_threads() does\r
110 the real work. In notmuch-time.c, I have implemented an alternative nice\r
111 and terse time representation, notmuch_time_relative8_date().\r
112 \r
113 I realized, though, that at this point I would have to hardcode things\r
114 like ANSI coloring into NOTMUCH_FORMAT_SUP.\r
115 \r
116 Also, any l10n (e.g. of time representation) would have to be hardcoded\r
117 as well (btw, anybody knows a library for human readable time\r
118 representations which supports l10n and i18n?).\r
119 \r
120 \r
121 So perhaps it's better to move the polishing into the client (Yeah!\r
122 Python to the rescue! ;-). But then, 'notmuch search' would need to\r
123 return some raw representation of the date field as well.\r
124 \r
125 \r
126 Any comment? Any other thoughts about this?\r
127 \r
128 \r
129 \r
130 Regards,\r
131     Gregor Hoffleit\r