[PATCH 4/4] Update NEWS for user.other_name
[notmuch-archives.git] / 3b / 7794bc40eddf4efc4cb72b6627b33c7faa7761
1 Return-Path: <pieter@praet.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 892D0429E54\r
6         for <notmuch@notmuchmail.org>; Sun, 22 Jan 2012 23:37:39 -0800 (PST)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.7\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
12         tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 tAlaVl7TY5Jv for <notmuch@notmuchmail.org>;\r
16         Sun, 22 Jan 2012 23:37:38 -0800 (PST)\r
17 Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com\r
18         [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
19         (No client certificate requested)\r
20         by olra.theworths.org (Postfix) with ESMTPS id 5737C429E40\r
21         for <notmuch@notmuchmail.org>; Sun, 22 Jan 2012 23:37:38 -0800 (PST)\r
22 Received: by wibhi8 with SMTP id hi8so378037wib.26\r
23         for <notmuch@notmuchmail.org>; Sun, 22 Jan 2012 23:37:37 -0800 (PST)\r
24 Received: by 10.180.93.193 with SMTP id cw1mr11453300wib.5.1327304256805;\r
25         Sun, 22 Jan 2012 23:37:36 -0800 (PST)\r
26 Received: from localhost ([109.131.95.182])\r
27         by mx.google.com with ESMTPS id cb8sm6919051wib.0.2012.01.22.23.37.35\r
28         (version=TLSv1/SSLv3 cipher=OTHER);\r
29         Sun, 22 Jan 2012 23:37:36 -0800 (PST)\r
30 From: Pieter Praet <pieter@praet.org>\r
31 To: Jameson Graef Rollins <jrollins@finestructure.net>,\r
32         Xavier Maillard <xma@gnu.org>, Austin Clements <amdragon@MIT.EDU>\r
33 Subject: Re: [PATCH 3/4] config: only set search.exclude_tags to "deleted;\r
34  spam;  " during setup\r
35 In-Reply-To: <87y5sz0ypj.fsf@servo.finestructure.net>\r
36 References: <1326586654-16840-3-git-send-email-amdragon@mit.edu>\r
37         <1327000744-25463-1-git-send-email-pieter@praet.org>\r
38         <1327000744-25463-4-git-send-email-pieter@praet.org>\r
39         <m2r4yr2xmy.fsf@kcals.intra.maillard.im>\r
40         <874nvnqrgq.fsf@servo.finestructure.net> <87ipk3au08.fsf@praet.org>\r
41         <87y5sz0ypj.fsf@servo.finestructure.net>\r
42 User-Agent: Notmuch/0.11+101~g94bf862 (http://notmuchmail.org) Emacs/23.3.1\r
43         (x86_64-unknown-linux-gnu)\r
44 Date: Mon, 23 Jan 2012 08:35:42 +0100\r
45 Message-ID: <87fwf6c1m9.fsf@praet.org>\r
46 MIME-Version: 1.0\r
47 X-Gm-Message-State:\r
48  ALoCoQnmlWBMimlQ/xGspfrQ/iQCTaFsmBIElvbSqHUYQ0K8REXr1oErCLXGPZAw9qul1lvP70tT\r
49 Content-Type: text/plain; charset=utf-8\r
50 Content-Transfer-Encoding: quoted-printable\r
51 Cc: Notmuch Mail <notmuch@notmuchmail.org>\r
52 X-BeenThere: notmuch@notmuchmail.org\r
53 X-Mailman-Version: 2.1.13\r
54 Precedence: list\r
55 List-Id: "Use and development of the notmuch mail system."\r
56         <notmuch.notmuchmail.org>\r
57 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
58         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
59 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
60 List-Post: <mailto:notmuch@notmuchmail.org>\r
61 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
62 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
63         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
64 X-List-Received-Date: Mon, 23 Jan 2012 07:37:39 -0000\r
65 \r
66 On Sun, 22 Jan 2012 21:34:00 -0800, Jameson Graef Rollins <jrollins@finestr=\r
67 ucture.net> wrote:\r
68 > On Mon, 23 Jan 2012 06:05:27 +0100, Pieter Praet <pieter@praet.org> wrote:\r
69 > > You definitely have a point, but then again, who are we to assume that\r
70 > > the terms "deleted" and "spam" have the *exact* same meaning for\r
71 > > everyone?  (also see id:"8739bbo0br.fsf@praet.org")\r
72 >=20\r
73 > Hrm.  I'm not sure I buy this.  Words already have meanings.  If we're\r
74 > going to start down a rabbit hole where we have to assume that users are\r
75 > making up crazy alternate meanings for words, we're going to run into a\r
76 > lot of problems.\r
77 >=20\r
78 \r
79 True, but we're talking about tags here.  Flexibility is their raison\r
80 d'=C3=AAtre.  If we're going to impose semi-arbitrary limitations, we do aw=\r
81 ay\r
82 with alot of the benefits we were looking for in the first place.\r
83 \r
84 > Notmuch, or at least the emacs interface, already assumes a specific\r
85 > meaning for certain terms, like most notably "inbox".  Given that we're\r
86 > dealing with english here, I think we have to assume common usage\r
87 > meanings for any of the words we're using to describe anything.\r
88 >=20\r
89 \r
90 Actually, we're only a small step away from being free to use whatever\r
91 tag(s) we want for this.  The term "inbox" is hardcoded in only 4\r
92 places, all of which are trivial to fix:\r
93 \r
94 - @ binary\r
95   - `notmuch_config_open', where it's only used as a fallback when\r
96     'new.tags' isn't set (and reused to suggest a default value for\r
97     'new.tags' when running setup).\r
98 \r
99 - @ Emacs UI\r
100   - `notmuch-saved-searches' (the function), where it's only used as\r
101     a fallback when `notmuch-saved-searches' (the var) isn't set.\r
102   - `notmuch-search-archive-thread'\r
103   - `notmuch-show-archive-thread-internal'\r
104 \r
105 > This argument breaks a little in regards to "delete" since we're not\r
106 > actually deleting anything in the sense of rm'ing it form the\r
107 > filesystem, so we're already changing the meaning a bit.  But see below.\r
108 >=20\r
109 \r
110 [...]\r
111 \r
112 > > IMHO, this is one of those options that should remain disabled until\r
113 > > *explicitly* set by the user.\r
114 >=20\r
115 > Ok, but then we're back to the incredibly prolonged discussion we've\r
116 > been having about adding "delete" keys.  If we disable this by default,\r
117 > but add "delete" keys, the user might be in for a different surprise if\r
118 > "deleted" messages keep showing up in searches.\r
119 >=20\r
120 > Basically we have two options as I see it:\r
121 >=20\r
122 > - add keys bindings to add "deleted" tags, and then *also* exclude\r
123 >   "tag:deleted" by default.\r
124 >=20\r
125 > - don't exclude anything by default, but then don't add any special keys\r
126 >   to handle "deleted" tags.\r
127 >=20\r
128 \r
129 Adding a key to "delete" messages doesn't necessarily have to mean that\r
130 the tag it adds should be hardcoded to "deleted".\r
131 \r
132 For example, our config file could contain something like this:\r
133 \r
134   #+begin_src conf\r
135     [new]\r
136     tags=3Dunread;inbox;\r
137 \r
138     [tag]\r
139     deleted=3Ddeleted;-inbox;\r
140     archive=3D-inbox;\r
141 \r
142     [search]\r
143     exclude_tags=3Ddeleted;spam;\r
144   #+end_src\r
145 \r
146   (where all entries under the [tag] section could be used as\r
147    aliases for "complex" tagging operations)\r
148 \r
149 ... and then we could "delete" messages using something like:\r
150 \r
151   #+begin_src emacs-lisp\r
152     (define-key notmuch-show-mode-map "d"\r
153       (lambda()\r
154         (interactive)\r
155         (notmuch-show-mod-tags\r
156           (split-string\r
157             (notmuch-config-get "tag.deleted") "\n"))\r
158         (notmuch-show-next-open-message)))\r
159   #+end_src\r
160 \r
161   (`notmuch-show-mod-tags' doesn't exist, of course, but see\r
162    `notmuch-message-mark-replied' for a good example of how\r
163    it could be work...)\r
164 \r
165 > There seemed to be a consensus forming that we in fact did want to add\r
166 > the "deleted" key bindings.  [...]\r
167 \r
168 +1.\r
169 \r
170 > [...] If we do that, then I think we should\r
171 > generate the config file to exclude "deleted" tags by default.\r
172 >=20\r
173 > jamie.\r
174 >=20\r
175 > PS: when I say "exclude tags by default" I actually mean that the\r
176 > setting should be added to the config file upon (re)generation.  Nothing\r
177 > should be excluded if nothing is set in the config file.\r
178 \r
179 Exactly!  This is actually the *only* reason I involved myself with this\r
180 whole conversation in the first place :)\r
181 \r
182 \r
183 Peace\r
184 \r
185 --=20\r
186 Pieter\r