On Fri, 22 Oct 2010 11:28:02 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote: > this is my second attempt to implement notmuch cat subcommand (the > first version was posted in > id:1271747793-17507-1-git-send-email-sojkam1@fel.cvut.cz). This > subcommand outputs the given message to stdout. Hi Michal, I'm *really* excited about this feature. The ability to more easily use notmuch over ssh is really appealing, and as I mentioned previously, I see this patch as a prerequisite for the maildir-synchronization work. > In this version the arguments are classical notmuch search terms and > not a filename as in the previous version. Emacs interface then uses > message-id to retrieve the message. Excellent. This is much better than before. > Some people suggested that cat could be implemented as a special > format of show subcommand. That would be possible, but it seems that > show command always constructs threads form the messages which means > that is executes several database queries. I consider this as > unnecessary overhead and for that reason cat is a separate subcommand. So I'll argue for "notmuch show --format=raw" here. You're correct that the current implementation of "notmuch show" calls notmuch_database_search_threads and --format=raw doesn't need to or want to do that. But see, for example, recent notmuch-search.c and you'll see that depending on the --output option, the "notmuch search" command will sometimes call search_threads and will sometimes call search_messages. So I think we want the same thing here. Meanwhile, since this command is only acting on the first message matched, don't you think it should be documented as only working with a search term that matches a single message? Then it could simply print an error message if the terms matched multiple messages.[*] -Carl [*] And we'll want that same behavior for "notmuch part" as well. That's already implemented in notmuch-show.c and should also be implemented as a sub-option of "notmuch show" I think, (which is probably another outstanding patch for me to review). So there might be room for a little code-sharing there. -- carl.d.worth@intel.com