Re: [PATCH v2 1/2] cli: introduce the concept of user defined hooks
authorAustin Clements <amdragon@MIT.EDU>
Sun, 4 Dec 2011 16:41:34 +0000 (11:41 +1900)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:40:34 +0000 (09:40 -0800)
f9/9488bdc4a5f24e15ea61e944515c608f77ced1 [new file with mode: 0644]

diff --git a/f9/9488bdc4a5f24e15ea61e944515c608f77ced1 b/f9/9488bdc4a5f24e15ea61e944515c608f77ced1
new file mode 100644 (file)
index 0000000..f65d65e
--- /dev/null
@@ -0,0 +1,108 @@
+Return-Path: <amdragon@mit.edu>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id C5608429E25\r
+       for <notmuch@notmuchmail.org>; Sun,  4 Dec 2011 08:39:51 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id DltElyE36y+4 for <notmuch@notmuchmail.org>;\r
+       Sun,  4 Dec 2011 08:39:51 -0800 (PST)\r
+Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU\r
+       [18.7.68.35])\r
+       by olra.theworths.org (Postfix) with ESMTP id 4B0F8429E21\r
+       for <notmuch@notmuchmail.org>; Sun,  4 Dec 2011 08:39:51 -0800 (PST)\r
+X-AuditID: 12074423-b7f266d0000008b8-25-4edba25613d5\r
+Received: from mailhub-auth-3.mit.edu ( [18.9.21.43])\r
+       by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP\r
+       id B3.BB.02232.652ABDE4; Sun,  4 Dec 2011 11:39:50 -0500 (EST)\r
+Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
+       by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id pB4GdnYH013939; \r
+       Sun, 4 Dec 2011 11:39:50 -0500\r
+Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
+       (authenticated bits=0)\r
+       (User authenticated as amdragon@ATHENA.MIT.EDU)\r
+       by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pB4GdmPS012528\r
+       (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
+       Sun, 4 Dec 2011 11:39:49 -0500 (EST)\r
+Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77)\r
+       (envelope-from <amdragon@mit.edu>)\r
+       id 1RXF8B-0005zM-5j; Sun, 04 Dec 2011 11:41:35 -0500\r
+Date: Sun, 4 Dec 2011 11:41:34 -0500\r
+From: Austin Clements <amdragon@MIT.EDU>\r
+To: Jani Nikula <jani@nikula.org>\r
+Subject: Re: [PATCH v2 1/2] cli: introduce the concept of user defined hooks\r
+Message-ID: <20111204164134.GT16194@mit.edu>\r
+References:\r
+ <7fbe6befcf31881a9bca672f55b93501249a220c.1322859389.git.jani@nikula.org>\r
+       <6688b09fffa2a66b496af78008102f88ab4e9450.1322953841.git.jani@nikula.org>\r
+       <20111204034210.GA16405@mit.edu> <87sjl0ldk0.fsf@nikula.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Content-Disposition: inline\r
+In-Reply-To: <87sjl0ldk0.fsf@nikula.org>\r
+User-Agent: Mutt/1.5.21 (2010-09-15)\r
+X-Brightmail-Tracker:\r
+ H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hTV1g1bdNvP4Nh8bYum6c4W12/OZHZg\r
+       8rh1/zW7x7NVt5gDmKK4bFJSczLLUov07RK4Mtr6zzIXTOaqWP77HlMD40/2LkZODgkBE4nG\r
+       J/cYIWwxiQv31rOB2EIC+xglXrdadjFyAdnrGSW2TX7ODJE4wSTxcWs2RGIJo8TCM7fAEiwC\r
+       KhK3/m8Gm8QmoCGxbf9yMFtEQFFi88n9YDazgLTEt9/NTCC2sICPRPfPXWBX8AroSMyb9owF\r
+       YugjRonLK59AJQQlTs58wgLRrCVx499LoGYOsEHL/3GAhDmBds0+1Ax2gyjQDVNObmObwCg0\r
+       C0n3LCTdsxC6FzAyr2KUTcmt0s1NzMwpTk3WLU5OzMtLLdI108vNLNFLTSndxAgKanYX5R2M\r
+       fw4qHWIU4GBU4uHNPHHLT4g1say4MvcQoyQHk5Iob+n8235CfEn5KZUZicUZ8UWlOanFhxgl\r
+       OJiVRHj5UoFyvCmJlVWpRfkwKWkOFiVxXpmdDn5CAumJJanZqakFqUUwWRkODiUJ3nMLgRoF\r
+       i1LTUyvSMnNKENJMHJwgw3mAhoPV8BYXJOYWZ6ZD5E8xKkqJ894ESQiAJDJK8+B6YUnnFaM4\r
+       0CvCvGdBqniACQuu+xXQYCagwYqNN0AGlyQipKQaGM0ebbst9V7T4TznRgtnxs01Umomi+/z\r
+       FXJK34jxlu978pQxOULK2u3d4SWcO/iD/vSwcLZ32tr/0P5r9FJNc0VumH6XbWdzwal0qa4t\r
+       wm6n/m4tu3B1Q+PiIj2tD2vqTutei1UvsomcO53h2rkctoajWculmtZ/O3TngvMGJo3tv3fe\r
+       O3FslxJLcUaioRZzUXEiAOez8ToVAwAA\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sun, 04 Dec 2011 16:39:51 -0000\r
+\r
+Quoth Jani Nikula on Dec 04 at  2:35 pm:\r
+> > > +int\r
+> > > +notmuch_run_hook (const char *db_path, const char *hook)\r
+> > > +{\r
+> > > +    char *hook_path;\r
+> > > +    int status = 0;\r
+> > \r
+> > You use status as both a notmuch_status_t and for generic C library\r
+> > results.  This seems a little weird.  You may or may not want to do\r
+> > anything about it.\r
+> \r
+> True, it's not consistent. I'll want to do something about it. I wonder\r
+> if it's worth returning anything other than ok/fail from this function\r
+> anyway.\r
+> \r
+> There seems to be some confusion in notmuch_status_t usage across\r
+> notmuch cli. Should notmuch cli return a notmuch_status_t as exit\r
+> status? It currently does at least in some cases, but it also returns\r
+> plain 1 too which is (unintentionally) NOTMUCH_STATUS_OUT_OF_MEMORY.\r
+> \r
+> Does it make sense for the cli to use the lib statuses internally\r
+> anyway; you wouldn't want to add new status codes to the lib just to be\r
+> able to use them in cli.\r
+\r
+I think the answer is that there's no good answer because error\r
+handling in C is so lame.  In this particular case, I'd say there's\r
+little point in distinguishing different errors (and especially no\r
+point in returning not-quite-appropriate status codes), so perhaps it\r
+should follow the 0/1 convention.\r