On Mon, Apr 27, 2020 at 9:21 PM Tomi Ollila <tomi.oll...@iki.fi> wrote: > > On Mon 2020-04-27 14:53:07 -0300, David Bremner wrote: > >> Quoting notmuch(1) > >> > >> OPTION SYNTAX > >> All options accepting an argument can be used with '=' > >> or ':' as a separator. For the cases where it's not ambiguous > >> (in particular excluding boolean options), a space can also be > >> used.
I definitively skipped over that warning, mainly because I was reading the man-page for the specific command (i.e. `notmuch-search`, etc.) that don't feature that warning. Please note that I understand "why" I get this behavior, and definitively I agree that it's my fault. However my initial report was intended to find a way that new users don't shoot themselves in the foot, especially since many will use `notmuch` from a script, and sometimes they don't thoroughly check the arguments passed by the user. > > Alternately, we could deprecate using whitespace for all options, > > produce explicit warnings to stderr when whitespace appears on the next > > was it so, that originally we did not support whitespace, but David > added that in some commit... >From a "correctness" point of view, this would be the best approach. However I think it could be too late to introduce it, and it would break too many integrations. > > release, remove the suggestion to use a whitespace separator from the > > documentation, and eventually phase it out entirely in some future > > release. > > Alternatively we could check that next arg is (case-insensitively) > (subset of) 'true', 'false', 'yes', 'no', '0', '1', 't', 'nil' > (but not tpyoes of these ;) and in that case have that as an option > value... This would be perhaps the best approach. However I don't think it would solve the issues for integrators that would not see these warnings in the logs, until it is too late. > ... would that work better for human user who just wants to be > fluent on command line -- frontends can then always use = and option > values... Perhaps there could be an additional option (either on the command line or in the configuration) that would apply "strict" checking, and not letting any other form except `--argument=value`, including the boolean flags, and failing loudly. I think this third option would enable much safer integrations. (BTW, this "strict" option could also apply to the parsing of the search terms, which most of the time are under the control of the end user.) Ciprian. _______________________________________________ notmuch mailing list firstname.lastname@example.org https://notmuchmail.org/mailman/listinfo/notmuch