Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id F3B916DE0AB8 for ; Sat, 25 Apr 2015 12:56:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 1.126 X-Spam-Level: * X-Spam-Status: No, score=1.126 tagged_above=-999 required=5 tests=[AWL=0.474, SPF_NEUTRAL=0.652] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S88OrLszDIv for ; Sat, 25 Apr 2015 12:56:33 -0700 (PDT) Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) by arlo.cworth.org (Postfix) with ESMTP id 6E3496DE028C for ; Sat, 25 Apr 2015 12:56:32 -0700 (PDT) Received: from guru.guru-group.fi (localhost [IPv6:::1]) by guru.guru-group.fi (Postfix) with ESMTP id 20A03100033; Sat, 25 Apr 2015 22:56:08 +0300 (EEST) From: Tomi Ollila To: David Bremner Subject: Re: argument parsing refactoring round3 In-Reply-To: <87mw2fwn0t.fsf@maritornes.cs.unb.ca> References: <871tjws8w8.fsf@qmul.ac.uk> <1428435042-16503-1-git-send-email-david@tethera.net> <20150408143147.GD5218@vilya.online.net> <87oamy41nv.fsf@maritornes.cs.unb.ca> <87mw2fwn0t.fsf@maritornes.cs.unb.ca> User-Agent: Notmuch/0.19+109~ge80275e (http://notmuchmail.org) Emacs/24.3.1 (x86_64-unknown-linux-gnu) X-Face: HhBM'cA~ MIME-Version: 1.0 Content-Type: text/plain Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 19:56:36 -0000 On Sat, Apr 11 2015, David Bremner wrote: > David Bremner writes: > >> guyzmo writes: >> >>> I was wondering whether you had considered actually using `docopt` to >>> generate the CLI parser from the output. > >> As it stands, I'm not particularly annoyed with the notmuch argument >> parsing code, so I mainly see negative issues about your proposal. > > On the other hand, I do find the config handling code annoying, so if > people have some ideas about that, I am interested to hear them. There > is now almost 1000 lines of C in notmuch-config.c, and despite some > efforts to streamline things, there is a lot of copying and pasting > every time someone wants to add a configuration option. I reviewed the changes -- last ones 'cursory' as I think those don't break any "real" functionality -- and if help works bad then one can always resort to testing and reading code >;)... ...but I did not test -- automated tests (to ensure it doesn't break anything be handy... more complete would limit anyone's interest to implement alternate option handling (even further). As much I also liked "better" option handling code new code (vast of that) would also require significant reviewing effort which no-one will like to do >;/ With that said, +1 from me to the config handling changes. (or should I give it some hand-testing (how?) Tomi > > d