Re: [PATCH] emacs: wash: make word-wrap bound message width
[notmuch-archives.git] / 5a / b37cdb84f8e32d4ff67f3073f2976702c57480
1 Return-Path: <sojkam1@fel.cvut.cz>\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 9FB94431FD0\r
6         for <notmuch@notmuchmail.org>; Thu,  7 Jul 2011 08:23:17 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: 0\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
12         autolearn=disabled\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 bEakV+C0iHIv for <notmuch@notmuchmail.org>;\r
16         Thu,  7 Jul 2011 08:23:16 -0700 (PDT)\r
17 Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])\r
18         by olra.theworths.org (Postfix) with ESMTP id 2D5A9431FB6\r
19         for <notmuch@notmuchmail.org>; Thu,  7 Jul 2011 08:23:16 -0700 (PDT)\r
20 Received: from localhost (unknown [192.168.200.4])\r
21         by max.feld.cvut.cz (Postfix) with ESMTP id E6E853CFE8E;\r
22         Thu,  7 Jul 2011 17:23:14 +0200 (CEST)\r
23 X-Virus-Scanned: IMAP AMAVIS\r
24 Received: from max.feld.cvut.cz ([192.168.200.1])\r
25         by localhost (styx.feld.cvut.cz [192.168.200.4]) (amavisd-new,\r
26         port 10044)\r
27         with ESMTP id YUvF4QW4hYbC; Thu,  7 Jul 2011 17:23:13 +0200 (CEST)\r
28 Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34])\r
29         by max.feld.cvut.cz (Postfix) with ESMTP id B2BC43CFE8D;\r
30         Thu,  7 Jul 2011 17:23:13 +0200 (CEST)\r
31 Received: from steelpick.2x.cz (unknown [141.76.49.12])\r
32         (Authenticated sender: sojkam1)\r
33         by imap.feld.cvut.cz (Postfix) with ESMTPSA id 801FEFA004;\r
34         Thu,  7 Jul 2011 17:23:13 +0200 (CEST)\r
35 Received: from wsh by steelpick.2x.cz with local (Exim 4.76)\r
36         (envelope-from <sojkam1@fel.cvut.cz>)\r
37         id 1QeqQ5-0006vw-9Z; Thu, 07 Jul 2011 17:23:13 +0200\r
38 From: Michal Sojka <sojkam1@fel.cvut.cz>\r
39 To: Daniel Schoepe <daniel.schoepe@googlemail.com>, notmuch@notmuchmail.org\r
40 Subject: Re: [PATCH v3 1/2] emacs: User-defined sections in notmuch-hello\r
41 In-Reply-To: <87oc17r38a.fsf@tredergarh.home.box>\r
42 References: <1309379221-5617-1-git-send-email-daniel.schoepe@googlemail.com>\r
43         <1309883030-28899-1-git-send-email-daniel.schoepe@googlemail.com>\r
44         <1309883030-28899-2-git-send-email-daniel.schoepe@googlemail.com>\r
45         <87fwmjabii.fsf@steelpick.2x.cz>\r
46         <87oc17r38a.fsf@tredergarh.home.box>\r
47 User-Agent: Notmuch/0.5-332-gf8bc48d (http://notmuchmail.org) Emacs/23.3.1\r
48         (x86_64-pc-linux-gnu)\r
49 Date: Thu, 07 Jul 2011 17:23:13 +0200\r
50 Message-ID: <871uy25d3y.fsf@steelpick.2x.cz>\r
51 MIME-Version: 1.0\r
52 Content-Type: text/plain; charset=us-ascii\r
53 X-BeenThere: notmuch@notmuchmail.org\r
54 X-Mailman-Version: 2.1.13\r
55 Precedence: list\r
56 List-Id: "Use and development of the notmuch mail system."\r
57         <notmuch.notmuchmail.org>\r
58 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
59         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
60 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
61 List-Post: <mailto:notmuch@notmuchmail.org>\r
62 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
63 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
64         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
65 X-List-Received-Date: Thu, 07 Jul 2011 15:23:18 -0000\r
66 \r
67 On Wed, 06 Jul 2011, Daniel Schoepe wrote:\r
68 Non-text part: multipart/signed\r
69 > On Wed, 06 Jul 2011 13:34:13 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote:\r
70 > > So my proposal is to forget about different queries for filters and\r
71 > > counts and having here only the following options: filter, hide-tags and\r
72 > > hide-if-empty.\r
73 > > \r
74 > > Then, the documentation would be simple: "This section displays buttons\r
75 > > for all tags of messages matching a FILTER. Optionally, some of these\r
76 > > tags may be hidden."\r
77 > > \r
78 > > Is there a use case, which is not covered by this?\r
79\r
80 > I'm not sure, I can imagine someone wanting to have an overview of all\r
81 > his tags, whether there are, e.g., unread messages or not.\r
82 \r
83 This wouldn't work for me. My all-tags section covers almost entire\r
84 screen and finding non-zero entries there is not very convenient. I find\r
85 much more useful to have a section saying: "Hey, you have unread\r
86 messages only for these three tags". Moreover, it wouldn't help me to see\r
87 non-zero number of unread messages and when I click the button I would\r
88 see all the messages, not only the unread ones. It simply seems very\r
89 confusing to me.\r
90 \r
91 > If we decide to keep this functionality, it should be inverted though,\r
92 > i.e. one has to explicitly specify :show-empty-searches to get them.\r
93 \r
94\r
95 > About the counts: I introduced this because Austin Clements says he\r
96 > finds it useful in his comment here:\r
97\r
98 > id:"BANLkTi=729DWai4q57iBSfz1wDhBXsmndQ@mail.gmail.com"\r
99 \r
100 I agree that it is useful to see unread counts, but it is not useful to\r
101 see all messages when I click the button.\r
102 \r
103 > > > +  :type\r
104 > > > +  (let ((opts\r
105 > > > +  '((:title (string :tag "Title for this section"))\r
106 > > > +    (:make-query (string :tag "Filter for each tag"))\r
107 > > > +    (:make-count (string :tag "Different query to generate counts"))\r
108 > > > +    (:hide-tags (repeat :tag "Tags that will be hidden" string))\r
109 > > \r
110 > > I can imagine, that :hide-tags could also be a (list of) regexp(es).\r
111 > > \r
112 > > > +    (:initially-hidden (boolean :tag "Hide this on startup?"))\r
113 > > \r
114 > > This is IMHO not needed here, as you always has to enable this section\r
115 > > manually.\r
116\r
117 > A user might still want to have the section collapsed when starting the\r
118 > notmuch UI and only have it shown when he needs it. (I use that for a\r
119 > section that displays unread counts for each tag).\r
120 \r
121 You are right. I use emacs --daemon so I actually initialize notmuch UI\r
122 only when emacs crashes or when I run out of battery power ;-)\r
123 > > > +;; only defined to avoid compilation warnings about free variables\r
124 > > > +(defvar notmuch-hello-target nil)\r
125 > > \r
126 > > Add the documentation as discussed above. Additionally, it seems that\r
127 > > having only the label in this variable is not enough, since the same\r
128 > > label can appear in multiple sections. Perhaps, we need both the title\r
129 > > of the section and the label here.\r
130\r
131 > What do you mean by label? "Custom function"? If yes, that element will\r
132 > have the actual function name in the input element next to it anyway.\r
133 \r
134 If I understand this variable correctly, it stores the label (text) of\r
135 the button you have your point at. This allows you to stay at the same\r
136 button after reloading of notmuch-hello even if the layout changes,\r
137 right? Then having the same named button in multiple sections results in\r
138 moving the first (or last) occurrence of this button when notmuch-hello\r
139 is reloaded.\r
140 \r
141\r
142 > > Perhaps you want to end this (and also all other) section with an empty\r
143 > > line so that the order of sections doesn't matter. I use sections in\r
144 > > this order: header, inbox, saved-searches and there is no space between\r
145 > > header and inbox and two spaces between inbox and saved-searches.\r
146\r
147 > My thinking was to have no section end with a newline and insert a\r
148 > newline between each section when building the notmuch-hello buffer, to\r
149 > prevent forgotten trailing newlines when defining a new section.\r
150 \r
151 This sounds reasonable.\r
152 \r
153 > > I might be useful to include here a link to the customization of this\r
154 > > page. Maybe, it would be useful to have notmuch-hello subgroup in\r
155 > > customization interface and link to this group. But creation of the\r
156 > > subgroup should be definitely in a separate patch.\r
157\r
158 > Yes definitely. Pieter Praet recently sent a patch reorganizing the\r
159 > customization options into subgroups, so I'll change it once that patch\r
160 > has been applied.\r
161 \r
162 Good.\r
163 \r
164 -Michal\r