[PATCH] CLI/restore: handle missing keys and values in config data.

[Daniel Kahn Gillmor]

On Sun 2018-01-07 20:12:14 -0400, David Bremner wrote:
> Daniel Kahn Gillmor <dkg at 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 at alice:~$ notmuch config set query.banana ''
0 dkg at alice:~$ notmuch config list | grep banana
1 dkg at alice:~$ notmuch config set search.banana ''
0 dkg at alice:~$ notmuch config list | grep banana
search.banana=
0 dkg at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20180209/ec3a3bd5/attachment.sig>