On Sun 2018-01-07 20:12:14 -0400, David Bremner wrote: > Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > >> On Sun 2018-01-07 17:30:25 -0400, David Bremner wrote: >>> Although such lines can't occur in notmuch dump output, they might be >>> useful for clearing config, and anyway segfaulting is not the best >>> error message. >> >> I don't think we want "notmuch restore" to actually clear any >> configurations (it's always been additive thus far and changing that >> seems dicey to me), but the patch itself here looks good to me. > > I'm not sure how to reconcile those two statements: the patch does clear > configuration if given a key without a value.
sorry, i didn't understand this well and am just now getting back to looking at it. I'd thought that this would not clear the config variable, but would instead set it to the empty string. But that doesn't appear to be correct... A few notes about the notmuch config as i'm wrapping my head back around it: * at least for config data stored in the database, a configuration entry with the value of the empty string is the same as an unset configuration value. is that right? is that the semantics we want? * for config data *not* stored in the database, a configuration entry with the value of the empty string is *different* from an unset configuration value. yikes! query.* is stored in the database, search.* is stored in the config file: 0 dkg@alice:~$ notmuch config set query.banana '' 0 dkg@alice:~$ notmuch config list | grep banana 1 dkg@alice:~$ notmuch config set search.banana '' 0 dkg@alice:~$ notmuch config list | grep banana search.banana= 0 dkg@alice:~$ * we have no "unset" subsubcommand for "notmuch config", only "set" and "query". should we have "unset" ? This is all very confusing and i don't see any principled way for users (or developers) to get their heads around it or to know what to expect. I've stated my preference before to move all the configuration into the database, and to deprecate the config file (except for the database directory itself?), because i think it would simplify and clarify matters. Alas, i don't have a lot of time to do this kind of refactoring right now. I'm fine with bremner's original proposal here, even though it apparently *does* currently clear the config variable from the database -- i don't think it makes things any more confusing than they were before, though i don't think that's a particularly high bar. In the future, i'd hope that such an entry in "notmuch restore" would *set* the variable to the empty string, but we don't have such a state at the moment. To be clear, there are situations where it's reasonable to have a config variable that you want to be the empty string, and you want that to be distinct from "unset". Consider the situation where there's a standard string that appears someplace. As a concrete example, let's imagine a config var reply.subject_prefix, which defaults to "Re: " (or to some locale-derived string. If it's unset, notmuch uses its defaults. if it's set to the empty string, then no subject prefix is applied on reply. At the same time, the user can set it to "about: " (or anything else) if they prefer. These are distinct (and useful) semantics, which it would be nice to have available for the notmuch config itself. --dkg
Description: PGP signature
_______________________________________________ notmuch mailing list firstname.lastname@example.org https://notmuchmail.org/mailman/listinfo/notmuch