[PATCH 6/8] cli: add support for batch tagging operations to "notmuch tag"

[Jani Nikula]

On Mon, 02 Apr 2012 14:43:16 -0700, Jameson Graef Rollins <jrollins at finestructure.net> wrote:
> So what if we instead modified the top level binary ("notmuch") to:
> 
> * add an option to specify that commands are to be processed from stdin
>   (--batch)
> 
> * when in batch mode the db is opened once at the beginning and locked
> 
> * commands are processed from stdin in the exact same form they are
>   specified on the command line ("tag +foo -- from:bar", "search
>   tag:foo", etc.).
> 
> * db is closed when EOF is reached.
> 
> That seems like it would be a generally much cleaner interface, and much
> more flexible.

Yes, it's more flexible, but what are the real benefits of such
flexibility? What other commands than tag/restore would truly benefit
from this? I might add that nobody has asked for such flexibility.

As to the cleanliness of the interface, all is well as long as no
characters needing escaping are used. With them, things get hairy. On
the command line, the shell provides the necessary escaping and quoting
mechanisms, and parsing to subcommand argv. I think it would be
confusing to require %NN style hex escaping on the command line where
shell mechanisms can be used, but also it would be a lot of work to
duplicate the shell escaping and quoting mechanisms to the stdin
parsing. For simplicity, I'd use hex escaping for stdin, and leave the
command line to the shell.

Finally, I'm not sure how the config and database open/close could be
cleanly duplicated in top level "notmuch" and the subcommands. Should
there be logic in the subcommands not to open the config/database if
they're already opened in top level? All of notmuch cli should also be
reworked to pass the config and database on to the subcommands. Not all
the commands need to open the database in read/write mode, and some
commands don't need to open the database at all, so it would not make
sense to move config/database open/close to top level completely.

In summary, I don't see enough value in this to put all the work
required into it. I think it's way more trouble than it's worth.


BR,
Jani.