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 9FC8A6DE014D for ; Tue, 30 Aug 2016 10:51:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[AWL=-0.098, 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 UxhKAkov7JSn for ; Tue, 30 Aug 2016 10:51:10 -0700 (PDT) Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) by arlo.cworth.org (Postfix) with ESMTP id A739A6DE0130 for ; Tue, 30 Aug 2016 10:51:09 -0700 (PDT) Received: from guru.guru-group.fi (localhost [IPv6:::1]) by guru.guru-group.fi (Postfix) with ESMTP id 22F31100104; Tue, 30 Aug 2016 20:51:28 +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 17:51:11 -0000 On Tue, Aug 30 2016, Tomi Ollila wrote: > 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). I forgot that this risk can be mitigated by a set of suitable tests... > > But, the above may be useless crap -- just I don't have more time to check > that out now...