From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 0F7E96DE02C3 for ; Tue, 30 Aug 2016 06:35:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.555 X-Spam-Level: X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[AWL=-0.097, 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 p3WPe4WXp_Ln for ; Tue, 30 Aug 2016 06:35:24 -0700 (PDT) Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) by arlo.cworth.org (Postfix) with ESMTP id 3DE806DE01EA for ; Tue, 30 Aug 2016 06:35:23 -0700 (PDT) Received: from guru.guru-group.fi (localhost [IPv6:::1]) by guru.guru-group.fi (Postfix) with ESMTP id 23ABF100104; Tue, 30 Aug 2016 16:35:45 +0300 (EEST) From: Tomi Ollila To: Erik Rybakken Cc: Jani Nikula , notmuch@notmuchmail.org, David Bremner Subject: Re: [PATCH] Add option `hooks.path` for setting the directory of hooks. In-Reply-To: References: <20160824163006.dzdvzjvkg5uxtrnh@dell> <87vayqnjr3.fsf@nikula.org> <20160824215430.ljugc3vevx4ve2gq@dell> <20160827132543.xlqxwu5owhc5x546@dell> User-Agent: Notmuch/0.22+61~geeecb9e (https://notmuchmail.org) Emacs/24.5.1 (x86_64-unknown-linux-gnu) X-Face: HhBM'cA~ MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.22 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: Tue, 30 Aug 2016 13:35:28 -0000 On Tue, Aug 30 2016, Tomi Ollila wrote: > On Sat, Aug 27 2016, Erik Rybakken wrote: > >> Hi, >> >> Thanks Tomi and David for the feedback! >> >> On Fri, Aug 26, 2016 at 02:32:19PM +0300, Tomi Ollila wrote: >> >>> ... but I can think of one problem there (if my memory server correctly) >> >> Yeah, I didn't think of that. I have been thinking about how to make the >> generated configuration show only the options that differ from the >> default, and have the default options commented out, but it got a bit too >> involved for me. >> >> However, I think I have another solution, and I included a updated patch >> for this. There is only one (*) difference from the first patch: >> >> When reading the configuration file and "hooks.path" is either unset or >> set to an empty string, we set config->hooks_path to be the expanded >> path "database.path/.notmuch/hooks", but we set the value of hooks.path in >> config->key_file to be an empty string. That way, when calling >> "notmuch_config_get_hooks_path", the expanded path gets returned, but when >> saving the config file, either from "notmuch setup" or "notmuch config set", >> the value will still be an empty string, given that it wasn't changed. >> >> I believe this is the easiest fix, and if this sounds good, I will start >> working on the tests. > > I kinda like how this would work... > > The code looked pretty good -- when did I git am to the email content > I got all from the beginning of this email to the commit message -- > so before next patches use git-format-patch and git-am... Check > > https://notmuchmail.org/contributing/ for more information... > > 2 things that came up after quick view > > 2) I wonder whether calling notmuch_config_get_hooks_path() could > be "lazier".... ARGH no :( -- it would make notmuch_config_get_hooks_path() > have different code than others and ... (**) That said, perhaps const char * notmuch_config_get_hooks_path (notmuch_config_t *config) { const char * hooks_path = _config_get (config, &config->hooks_path, "hooks", "path"); if (hooks_path == NULL || hooks_path[0] == '\0') { hooks_path = talloc_asprintf (config, "%s/.notmuch/hooks", notmuch_config_get_database_path (config)); _config_set(config, &config->hooks_path, "hooks", "path", hooks_path); } return hooks_path; } But, it takes quite a bit of careful examination to check whether that works as expected, and I always think whether some accidental fragileness there causes that stored value to be dumped to the configuration file (now, or in later changes). But, the above may be useless crap -- just I don't have more time to check that out now...