1 Return-Path: <beheerder@tekenbeetziekten.nl>
\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 50100431FB6
\r
6 for <notmuch@notmuchmail.org>; Sat, 2 Feb 2013 16:07:27 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
\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 tcCSguf1Ipw5 for <notmuch@notmuchmail.org>;
\r
16 Sat, 2 Feb 2013 16:07:24 -0800 (PST)
\r
17 Received: from srv047132.webreus.nl (srv047132.webreus.nl [46.235.47.132])
\r
18 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
\r
19 (No client certificate requested)
\r
20 by olra.theworths.org (Postfix) with ESMTPS id BE94E431FAE
\r
21 for <notmuch@notmuchmail.org>; Sat, 2 Feb 2013 16:07:23 -0800 (PST)
\r
22 Received: (qmail 19805 invoked from network); 3 Feb 2013 01:07:20 +0100
\r
23 Received: from ip73-109-210-87.adsl2.static.versatel.nl (HELO PCvangebruike)
\r
25 by srv047132.webreus.nl with SMTP; 3 Feb 2013 01:07:11 +0100
\r
26 From: "Robert Mast" <beheerder@tekenbeetziekten.nl>
\r
27 To: "'David Bremner'" <david@tethera.net>
\r
28 References: <000001cdfcd9$82500f00$86f02d00$@nl>
\r
29 <CA+pa1O0mTxkj_FMQH_jXWajmUAKHWbMsB4Yhp_4UX7hnhwgBrg@mail.gmail.com>
\r
30 <000001ce0161$5da40990$18ec1cb0$@nl>
\r
31 <87a9rml9pm.fsf@zancas.localnet>
\r
32 In-Reply-To: <87a9rml9pm.fsf@zancas.localnet>
\r
33 Subject: RE: [Spam-verdenking][english 100%] RE: Reply all - issue
\r
34 Date: Sun, 3 Feb 2013 01:06:58 +0100
\r
35 Message-ID: <005401ce01a2$62293300$267b9900$@nl>
\r
37 Content-Type: text/plain;
\r
39 Content-Transfer-Encoding: quoted-printable
\r
40 X-Mailer: Microsoft Office Outlook 12.0
\r
41 Thread-Index: Ac4Bh0PMAEUftH8lRH6w+fV5DvJa7QABgqoQ
\r
42 Content-Language: nl
\r
43 Cc: notmuch@notmuchmail.org
\r
44 X-BeenThere: notmuch@notmuchmail.org
\r
45 X-Mailman-Version: 2.1.13
\r
47 List-Id: "Use and development of the notmuch mail system."
\r
48 <notmuch.notmuchmail.org>
\r
49 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
50 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
51 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
52 List-Post: <mailto:notmuch@notmuchmail.org>
\r
53 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
54 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
55 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
56 X-List-Received-Date: Sun, 03 Feb 2013 00:07:27 -0000
\r
58 Thanks for the guidelines!
\r
60 One answer I couldn't find under coding: Do you all develop with =
\r
61 emacs/GDB or is there a more visual and intuitive IDE to code with and =
\r
62 load/show the dependency-tree? I only debugged some C-code with emacs 15 =
\r
63 years ago and feel quite clumsy to get emacs to function like a proper =
\r
68 I like your last suggestion at #5) of the header-regexp and agree to =
\r
69 first work on the design-issues left before coding:
\r
71 @#6): I doubt whether I should tamper with threading heuristics at =
\r
72 all at the level of /lib/database.cc. Does anyone know whether the MUA's =
\r
73 using notmuch depend on thread-id's at the level of database.cc, or will =
\r
74 MUA's respect the different threads coming from seeding =
\r
75 lib/thread.cc/_notmuch_thread_create with all known messages except =
\r
76 already processed messages as is done with notmuch_query_search_threads?
\r
78 If I let lib/thread.cc/_notmuch_thread_create only 'eat' everything from =
\r
79 'match_set' for a stripped subject the 'seed'-message of another subject =
\r
80 within the same thread will then lead to another created thread within =
\r
83 If I start coding this I can try the result with mutt-kz/notmuch and =
\r
86 My aim with getting notmuch working well will be providing a base for =
\r
87 reviving something like mail2forum for phpBB3 with =
\r
88 mailcompression-capabilities to prevent for mailthreads to be copied in =
\r
89 again and again with every mailed answer.
\r
91 I think that can be accomplished by keeping the original mails as well =
\r
92 and compress the forum-threads to sup-like threads (by hiding quoted =
\r
96 -----Oorspronkelijk bericht-----
\r
97 Van: David Bremner [mailto:david@tethera.net]=20
\r
98 Verzonden: zaterdag 2 februari 2013 21:53
\r
100 CC: notmuch@notmuchmail.org
\r
101 Onderwerp: [Spam-verdenking][english 100%] RE: Reply all - issue
\r
103 Robert Mast <beheerder@tekenbeetziekten.nl> writes:
\r
106 > Anyone interested in me patching Notmuch, or shall I keep the changes=20
\r
112 If you have patches, and you want feedback on them, then you are of =
\r
113 course welcome to send them to the list. Previous experience suggests =
\r
114 us that it is often faster in the long run (in terms of actually getting =
\r
115 code into notmuch) to take time to work out the design issues before =
\r
116 starting coding. Some suggestions/comments:
\r
118 1) See http://notmuchmail.org/contributing/ for some general hints on
\r
119 contributing code to notmuch.
\r
121 2) Make sure whatever threading heuristic you use is deterministic, and
\r
122 robust in the face of messages arriving in different orders, and
\r
123 munging of headers by mailing lists (subjects in particular get
\r
124 munged fairly often). =20
\r
126 3) In particular, it seems important that "notmuch dump" followed by
\r
127 "notmuch restore" (possibly followed by notmuch new?) yields =
\r
129 or equivalent thread structure
\r
131 4) Since threading heuristics are a matter of taste (i.e. not everyone
\r
132 is convinced that the way Gmail does it is the way notmuch should),
\r
133 you'll need to make this configurable. One constraint is that the
\r
134 library itself (under ./lib) is should not read configuration files
\r
135 (or environment variables, although it violates this for debugging).
\r
136 This just means you will have to change the API to pass configuration
\r
137 information in to certain routines.
\r
139 5) I'd say it's more important that you can shut off the heuristic
\r
140 completely than have special handling for git (or other version
\r
141 control system) patch series. If you do decide to add some special
\r
142 handling for patch series, I'd suggest making it as generic as
\r
143 possible, perhaps a configurable list of (header, regex) values that
\r
144 disable the thread splitting heuristics.
\r
146 6) Decide how, if at all your design will support manually joining
\r
147 threads together. I think an acceptable answer would probably be
\r
148 "disable all thread splitting heuristics and rebuild the
\r
149 database". I'm not sure if it's feasible to do anything nicer than
\r