24/e7c113ae564bae59884afc2e656b5db83ae3e4

   1 Return-Path: <tomi.ollila@iki.fi>\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 F3B916DE0AB8\r
   6  for <notmuch@notmuchmail.org>; Sat, 25 Apr 2015 12:56:35 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 1.126\r
  10 X-Spam-Level: *\r
  11 X-Spam-Status: No, score=1.126 tagged_above=-999 required=5 tests=[AWL=0.474, \r
  12  SPF_NEUTRAL=0.652] autolearn=disabled\r
  13 Received: from arlo.cworth.org ([127.0.0.1])\r
  14  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15  with ESMTP id 0S88OrLszDIv for <notmuch@notmuchmail.org>;\r
  16  Sat, 25 Apr 2015 12:56:33 -0700 (PDT)\r
  17 Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
  18  by arlo.cworth.org (Postfix) with ESMTP id 6E3496DE028C\r
  19  for <notmuch@notmuchmail.org>; Sat, 25 Apr 2015 12:56:32 -0700 (PDT)\r
  20 Received: from guru.guru-group.fi (localhost [IPv6:::1])\r
  21  by guru.guru-group.fi (Postfix) with ESMTP id 20A03100033;\r
  22  Sat, 25 Apr 2015 22:56:08 +0300 (EEST)\r
  23 From: Tomi Ollila <tomi.ollila@iki.fi>\r
  24 To: David Bremner <david@tethera.net>\r
  25 Subject: Re: argument parsing refactoring round3\r
  26 In-Reply-To: <87mw2fwn0t.fsf@maritornes.cs.unb.ca>\r
  27 References: <871tjws8w8.fsf@qmul.ac.uk>\r
  28  <1428435042-16503-1-git-send-email-david@tethera.net>\r
  29  <20150408143147.GD5218@vilya.online.net>\r
  30  <87oamy41nv.fsf@maritornes.cs.unb.ca> <87mw2fwn0t.fsf@maritornes.cs.unb.ca>\r
  31 User-Agent: Notmuch/0.19+109~ge80275e (http://notmuchmail.org) Emacs/24.3.1\r
  32  (x86_64-unknown-linux-gnu)\r
  33 X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
  34  $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
  35  !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
  36 Date: Sat, 25 Apr 2015 22:56:07 +0300\r
  37 Message-ID: <m2oamcyobs.fsf@guru.guru-group.fi>\r
  38 MIME-Version: 1.0\r
  39 Content-Type: text/plain\r
  40 Cc: notmuch@notmuchmail.org\r
  41 X-BeenThere: notmuch@notmuchmail.org\r
  42 X-Mailman-Version: 2.1.18\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: <http://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: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  52  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  53 X-List-Received-Date: Sat, 25 Apr 2015 19:56:36 -0000\r
  54 \r
  55 On Sat, Apr 11 2015, David Bremner <david@tethera.net> wrote:\r
  56 \r
  57 > David Bremner <david@tethera.net> writes:\r
  58 >\r
  59 >> guyzmo <guyzmo+notmuch@m0g.net> writes:\r
  60 >>\r
  61 >>> I was wondering whether you had considered actually using `docopt` to\r
  62 >>> generate the CLI parser from the output.\r
  63 >\r
  64 >> As it stands, I'm not particularly annoyed with the notmuch argument\r
  65 >> parsing code, so I mainly see negative issues about your proposal.\r
  66 >\r
  67 > On the other hand, I do find the config handling code annoying, so if\r
  68 > people have some ideas about that, I am interested to hear them.  There\r
  69 > is now almost 1000 lines of C in notmuch-config.c, and despite some\r
  70 > efforts to streamline things, there is a lot of copying and pasting\r
  71 > every time someone wants to add a configuration option.\r
  72 \r
  73 I reviewed the changes -- last ones 'cursory' as I think those don't \r
  74 break any "real" functionality -- and if help works bad then one can\r
  75 always resort to testing and reading code >;)...\r
  76 \r
  77 ...but I did not test -- automated tests (to ensure it doesn't break\r
  78 anything be handy... more complete would limit anyone's interest to\r
  79 implement alternate option handling (even further).\r
  80 \r
  81 As much I also liked "better" option handling code new code (vast of that)\r
  82 would also require significant reviewing effort which no-one will like\r
  83 to do >;/\r
  84 \r
  85 With that said, +1 from me to the config handling changes. \r
  86 (or should I give it some hand-testing (how?)\r
  87 \r
  88 Tomi\r
  89 \r
  90 >\r
  91 > d\r