On Wed, Apr 29 2020, Ciprian Dorin Craciun <ciprian.craciun@gmail.com> wrote: > 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". :) This is a good point. The CLI might be "poor", but important apps like notmuch-emacs are using them, so we should be careful about changing the interface. > 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`. Also a good point. I guess the --flag=value interface is a safer/easier one to converge on. > 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. This actually sounds like a pretty good idea... jamie. _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch