On Wed, Apr 29, 2020 at 6:39 PM David Bremner <david@tethera.net> wrote: > I guess I'm a bit leery of removing UI features that presumably at least > some people rely on. It's pretty upsetting to have sofware break one's > muscle memory. I think there are two complete different use-cases for the `notmuch` binary: * a simple CLI to query the database, in which case the current flags seem OK; * a "poor-mans" API to query the database, more bellow; (I know there already exists an `libnotmuch` API accessible in many programming languages. However for prototyping, and even for safety and robustness, when performance isn't an issue, I find the tool-based approach much more resilient.) Now about the "API" use-case, I assume that at the moment many users have already integrated `notmuch` as it is with the current flags and behaviour. Thus I agree that changing any flags in backward incompatible way would make a lot of people unhappy, and will generate perhaps quite a bit of "customer support". :) However, even with my `--strict` argument, I was perhaps leaning toward adding a more API-friendly command line parser, that would basically only take arguments in the form `--flag=value`, anything else being considered a search term, and anything not a flag but before a single `--` should be considered an error. Regarding the `--boolean` vs `--no-boolean` it does solve the strictness problem, however it makes the life of script developers quite hard, as now he has a `case` or `if/then/else`. Therefore I would say that `--flag=value` is the best option as it can be simply written as `--flag={FLAG:-true}` or in Python for example `"--flag=%s" % _flag`. Thinking even further uppon this, perhaps an even simpler idea would be to provide a new command, like for example `notmuch api` that takes on `stdin` a JSON with a specific format and does its job. Ciprian. _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch