Re: [RFC] Content-Description when naming MIME parts in Emacs mode
[notmuch-archives.git] / 06 / a6010559a4bb9a0fdb579aa82366daa1df21cf
1 Return-Path: <jani@nikula.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 56B77431FB6\r
6         for <notmuch@notmuchmail.org>; Tue,  3 Apr 2012 01:21:37 -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.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 os68jCbN4LYb for <notmuch@notmuchmail.org>;\r
16         Tue,  3 Apr 2012 01:21:36 -0700 (PDT)\r
17 Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com\r
18         [209.85.216.46]) (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 A481C431FAE\r
21         for <notmuch@notmuchmail.org>; Tue,  3 Apr 2012 01:21:36 -0700 (PDT)\r
22 Received: by qatm19 with SMTP id m19so2470342qat.5\r
23         for <notmuch@notmuchmail.org>; Tue, 03 Apr 2012 01:21:36 -0700 (PDT)\r
24 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
25         d=google.com; s=20120113;\r
26         h=from:to:cc:subject:in-reply-to:references:user-agent:date\r
27         :message-id:mime-version:content-type:x-gm-message-state;\r
28         bh=v/Od0crtF1prlrbcjpjBYSdger8i6Y0HfSDubwxcIJE=;\r
29         b=BWxkUlMl7hMbOMmNR19m6qF03xOKkAB/IyI0nWnjIsp2t9hIIG5xzn3YcbS/5/34L5\r
30         m1SW5NnwexyoC/ltdIrSLvK71bcXkYimBGXbqxYrDV1g5ckmzfuDnz+D+vYkstWoOKo1\r
31         nQXYFsL4mr+bCiEYSkI5/7kkihTodjLeowb0fYSncP4Y1rkfMC4FHC7wnYbcO2skYh9f\r
32         OWF5aVZK98J842zpMldU9Y5tkSEkTonSzpDNPrsKXnzSAmK/7dxZB8OFJjqI6s/XHd8w\r
33         JWaXiHCq+NbfA8AK/o/m3vEMRieR3moMX52R7vOd1AptAUWNziC3IkEBjB8PUt6Aljk3\r
34         1bKQ==\r
35 Received: by 10.224.59.204 with SMTP id m12mr15538060qah.37.1333441295985;\r
36         Tue, 03 Apr 2012 01:21:35 -0700 (PDT)\r
37 Received: from localhost (nikula.org. [92.243.24.172])\r
38         by mx.google.com with ESMTPS id w9sm38798041qao.0.2012.04.03.01.21.32\r
39         (version=SSLv3 cipher=OTHER); Tue, 03 Apr 2012 01:21:34 -0700 (PDT)\r
40 From: Jani Nikula <jani@nikula.org>\r
41 To: Jameson Graef Rollins <jrollins@finestructure.net>\r
42 Subject: Re: [PATCH 6/8] cli: add support for batch tagging operations to\r
43         "notmuch tag"\r
44 In-Reply-To: <87d37p4xor.fsf@servo.finestructure.net>\r
45 References: <cover.1333231401.git.jani@nikula.org>\r
46         <f360a40bed50208d146aee8b06946b1b8315e818.1333231401.git.jani@nikula.org>\r
47         <87ty123tpc.fsf@servo.finestructure.net>\r
48         <87aa2tc22z.fsf@zancas.localnet>\r
49         <87iphh50hz.fsf@servo.finestructure.net>\r
50         <CAB+hUn_J9oOmbWaQ+_2yGG6i6ecDXbfJWYbpaYx_kbSnAH+EcA@mail.gmail.com>\r
51         <87fwcl4yr8.fsf@servo.finestructure.net>\r
52         <CAB+hUn-5yB15na2kFMZOjOEujKQTWHiefvgQYsT4Zi3UOzKwQw@mail.gmail.com>\r
53         <87d37p4xor.fsf@servo.finestructure.net>\r
54 User-Agent: Notmuch/0.11.1+222~ga47a98c (http://notmuchmail.org) Emacs/23.1.1\r
55         (i686-pc-linux-gnu)\r
56 Date: Tue, 03 Apr 2012 08:21:31 +0000\r
57 Message-ID: <87pqbpxm2c.fsf@nikula.org>\r
58 MIME-Version: 1.0\r
59 Content-Type: text/plain; charset=us-ascii\r
60 X-Gm-Message-State:\r
61  ALoCoQmhE6xzmoohG/zbOOuuKWop/TRUyk/GGOYVq+bgf3p5cyLZ005d7Oyo93FLZc6/R9KDvh+4\r
62 Cc: Notmuch Mail <notmuch@notmuchmail.org>\r
63 X-BeenThere: notmuch@notmuchmail.org\r
64 X-Mailman-Version: 2.1.13\r
65 Precedence: list\r
66 List-Id: "Use and development of the notmuch mail system."\r
67         <notmuch.notmuchmail.org>\r
68 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
69         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
70 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
71 List-Post: <mailto:notmuch@notmuchmail.org>\r
72 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
73 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
74         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
75 X-List-Received-Date: Tue, 03 Apr 2012 08:21:37 -0000\r
76 \r
77 On Mon, 02 Apr 2012 14:43:16 -0700, Jameson Graef Rollins <jrollins@finestructure.net> wrote:\r
78 > So what if we instead modified the top level binary ("notmuch") to:\r
79\r
80 > * add an option to specify that commands are to be processed from stdin\r
81 >   (--batch)\r
82\r
83 > * when in batch mode the db is opened once at the beginning and locked\r
84\r
85 > * commands are processed from stdin in the exact same form they are\r
86 >   specified on the command line ("tag +foo -- from:bar", "search\r
87 >   tag:foo", etc.).\r
88\r
89 > * db is closed when EOF is reached.\r
90\r
91 > That seems like it would be a generally much cleaner interface, and much\r
92 > more flexible.\r
93 \r
94 Yes, it's more flexible, but what are the real benefits of such\r
95 flexibility? What other commands than tag/restore would truly benefit\r
96 from this? I might add that nobody has asked for such flexibility.\r
97 \r
98 As to the cleanliness of the interface, all is well as long as no\r
99 characters needing escaping are used. With them, things get hairy. On\r
100 the command line, the shell provides the necessary escaping and quoting\r
101 mechanisms, and parsing to subcommand argv. I think it would be\r
102 confusing to require %NN style hex escaping on the command line where\r
103 shell mechanisms can be used, but also it would be a lot of work to\r
104 duplicate the shell escaping and quoting mechanisms to the stdin\r
105 parsing. For simplicity, I'd use hex escaping for stdin, and leave the\r
106 command line to the shell.\r
107 \r
108 Finally, I'm not sure how the config and database open/close could be\r
109 cleanly duplicated in top level "notmuch" and the subcommands. Should\r
110 there be logic in the subcommands not to open the config/database if\r
111 they're already opened in top level? All of notmuch cli should also be\r
112 reworked to pass the config and database on to the subcommands. Not all\r
113 the commands need to open the database in read/write mode, and some\r
114 commands don't need to open the database at all, so it would not make\r
115 sense to move config/database open/close to top level completely.\r
116 \r
117 In summary, I don't see enough value in this to put all the work\r
118 required into it. I think it's way more trouble than it's worth.\r
119 \r
120 \r
121 BR,\r
122 Jani.\r