Re: [PATCH v4 13/16] add indexopts to notmuch python bindings.
[notmuch-archives.git] / 92 / 018fd63ea24b9a3d8a34a9125a0a31910bce5b
1 Return-Path: <david@tethera.net>\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 arlo.cworth.org (Postfix) with ESMTP id B03706DE034D\r
6  for <notmuch@notmuchmail.org>; Sat, 30 Apr 2016 04:54:05 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.015\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.015 tagged_above=-999 required=5\r
12  tests=[AWL=-0.004, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01]\r
13  autolearn=disabled\r
14 Received: from arlo.cworth.org ([127.0.0.1])\r
15  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
16  with ESMTP id l4n0nQWwS4KZ for <notmuch@notmuchmail.org>;\r
17  Sat, 30 Apr 2016 04:53:57 -0700 (PDT)\r
18 Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197])\r
19  by arlo.cworth.org (Postfix) with ESMTPS id C5F6C6DE0022\r
20  for <notmuch@notmuchmail.org>; Sat, 30 Apr 2016 04:53:57 -0700 (PDT)\r
21 Received: from remotemail by fethera.tethera.net with local (Exim 4.84)\r
22  (envelope-from <david@tethera.net>)\r
23  id 1awTT4-0005Jc-3b; Sat, 30 Apr 2016 07:53:50 -0400\r
24 Received: (nullmailer pid 5396 invoked by uid 1000);\r
25  Sat, 30 Apr 2016 11:53:52 -0000\r
26 From: David Bremner <david@tethera.net>\r
27 To: Tomi Ollila <tomi.ollila@iki.fi>, notmuch@notmuchmail.org\r
28 Subject: Re: [Patch v2 04/13] lib/cli: add library API / CLI for compile time\r
29  options\r
30 In-Reply-To: <m27ffjvt9j.fsf@guru.guru-group.fi>\r
31 References: <1459015043-8460-1-git-send-email-david@tethera.net>\r
32  <1459015043-8460-5-git-send-email-david@tethera.net>\r
33  <m27ffjvt9j.fsf@guru.guru-group.fi>\r
34 User-Agent: Notmuch/0.21+99~gd93d377 (http://notmuchmail.org) Emacs/24.5.1\r
35  (x86_64-pc-linux-gnu)\r
36 Reply-To: me@example.com\r
37 Date: Sat, 30 Apr 2016 08:53:52 -0300\r
38 Message-ID: <87inyz8g8f.fsf@zancas.localnet>\r
39 MIME-Version: 1.0\r
40 Content-Type: text/plain\r
41 X-BeenThere: notmuch@notmuchmail.org\r
42 X-Mailman-Version: 2.1.20\r
43 Precedence: list\r
44 List-Id: "Use and development of the notmuch mail system."\r
45  <notmuch.notmuchmail.org>\r
46 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
47  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
48 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
49 List-Post: <mailto:notmuch@notmuchmail.org>\r
50 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
51 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
52  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
53 X-List-Received-Date: Sat, 30 Apr 2016 11:54:05 -0000\r
54 \r
55 Tomi Ollila <tomi.ollila@iki.fi> writes:\r
56 \r
57 > On Sat, Mar 26 2016, David Bremner <david@tethera.net> wrote:\r
58 >\r
59 >\r
60 > notmuch_bool_t\r
61 > notmuch_options_get (const char *name) {\r
62 >     if (STRNCMP_LITERAL (name, "compact") == 0) {\r
63 >       return HAVE_XAPIAN_COMPACT;\r
64 >       // or return HAVE_XAPIAN_COMPACT? TRUE: FALSE;\r
65 >       // or return !! HAVE_XAPIAN_COMPACT;\r
66 >     } else if (STRNCMP_LITERAL (name, "field_processor") == 0) {\r
67 >       return HAVE_XAPIAN_FIELD_PROCESSOR;\r
68 >     } else {\r
69 >       return FALSE;\r
70 >     }\r
71 > }\r
72 \r
73 I have no real objection to this. It's a bit slower than matching\r
74 against an enum, but I don't see this being in any performance critical\r
75 paths.\r
76 \r
77 >\r
78 > ... note: if this notmuch_options_present () function prevails, fix\r
79 > the later #if check ;D\r
80 >\r
81 > ... and\r
82 >\r
83 > void\r
84 > _notmuch_config_list_options () {\r
85 >     printf("options.compact=%s\n",\r
86 >          HAVE_XAPIAN_COMPACT ? "true" : "false");\r
87 >     printf("options.field_processor=%s\n",\r
88 >          HAVE_XAPIAN_FIELD_PROCESSOR ? "true" : "false");\r
89 > }\r
90 >\r
91 \r
92 This I'm not so sure about. There's a subtle distinction between what is\r
93 supported in the CLI and what is supported in the lib, and we really\r
94 want the latter. So I do think _some_ library routine is needed.\r
95 \r
96 > (kept the 'options' naming and prefix in this context)\r
97 \r
98 As far as the naming goes, I agree options is a bit weird. We could call\r
99 these things library features and the existing ones database features,\r
100 since the the latter are not really exposed to users.  Other possible\r
101 words are\r
102 \r
103       trait\r
104       attribute\r
105       property\r
106       \r
107       \r