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 13D026DE01D3 for ; Wed, 13 Jan 2016 04:25:18 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[AWL=0.242, RP_MATCHES_RCVD=-0.55, SPF_PASS=-0.001] 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 WpOKHVoINKxy for ; Wed, 13 Jan 2016 04:25:15 -0800 (PST) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id A0AB26DE0159 for ; Wed, 13 Jan 2016 04:25:14 -0800 (PST) Received: from remotemail by fethera.tethera.net with local (Exim 4.84) (envelope-from ) id 1aJKU2-0007SK-Ej; Wed, 13 Jan 2016 07:25:02 -0500 Received: (nullmailer pid 2582 invoked by uid 1000); Wed, 13 Jan 2016 12:25:10 -0000 From: David Bremner To: Konrad Hinsen , notmuch@notmuchmail.org Subject: Re: Binding access to ~/.notmuch-config In-Reply-To: <5696343B.2070907@fastmail.net> References: <5694CA65.8010400@fastmail.net> <87bn8r54dz.fsf@zancas.localnet> <8737u26cpg.fsf@zancas.localnet> <8760yy4o3w.fsf@tesseract.cs.unb.ca> <20160112191350.GE372@odin.tremily.us> <5696343B.2070907@fastmail.net> User-Agent: Notmuch/0.21+26~g9404723 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 13 Jan 2016 08:25:10 -0400 Message-ID: <87wprd4qft.fsf@zancas.localnet> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.20 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: Wed, 13 Jan 2016 12:25:18 -0000 Konrad Hinsen writes: > I agree. I see notmuch as a collection of CLI tools, some of which are > part of the distribution and others are written by myself for my > specific needs. I'd like them all to share a single configuration file. > In fact, I'd love to be able to add sections specific to my Python scripts. Yes, I understand that it's convenient, but the current set up is not really very robust. The python bindings are making assumptions about a file format that has never been documented, and whose stability has never been promised. It's roughly like calling private functions not part of the published API. Sometimes it's the only way to do something, but that doesn't mean it won't break. I think we'll eventually want to provide some config related API, but having having arbitrary programs reading and writing this file isn't it, IMHO. In particular upcoming changes may move some configuration items out of this file and into a library level configuration API. d