Re: [notmuch] pull request
On Thu, 01 Apr 2010 14:09:57 -0700, Carl Worth wrote: > On Thu, 01 Apr 2010 15:41:03 +0100, David Edmondson wrote: > > Carl, a couple of patches that I'd like you to consider. They are the > > first two on the `dme' branch of git://github.com/dme/notmuch.git. The updated changes are on the 'dme-for-cworth' branch now. > > http://github.com/dme/notmuch/commit/f86254e4509ed02731aa3eaa8541df1f2d11e400 > > > notmuch-show: Add unix and pretty dates to the JSON output > > > > > > Include a 'date_unix' and 'date_pretty' field in the JSON output for > > > each message. 'date_pretty' can be used by a UI implementation, > > > whereas 'date_unix' is useful when scripting. > > With "date_unix" it's easy enough to guess what the value is. But > "date_pretty" is much more ambiguous. I assumed that this would be an > RFC 822 date string, (but then found that it's the relative date that > "notmuch show" is using currently). > > I think I'd rather see that named "date_relative", (or dropped with the > expectation that callers can decide how to format dates on their own). I renamed it to 'date_relative'. Keeping the creation of the relative date strings in one place struck me as a good idea - there will consistency between the two places it is used (search mode and show mode) and if the `notmuch' command is localised the Emacs UI will immediately benefit. > > > The search terms should match only a single message > > > (e.g. id:f...@bar.com). The part number specified refers to the part > > > identifiers output by `notmuch show'. The content of the part is written > > > the stdout with no formatting or identification marks. It is not JSON > > > formatted. > > The above documentation isn't quite complete to me. Is MIME decoding > handled by this or not? Also, the documentation says the search terms > "should match" only one message, but what does the implementation do if > more than one message is matched? It would be good to document that as > well. > > More significantly, this level of documentation needs to be put into the > "notmuch help" output (instead of the placeholder that's there in the > current patch). It also needs to be added to the man page in > notmuch.1. The documentation is updated. Sorry for being lazy. > > The second of these (part) has been the topic of some > > discussion. There's a suggestion that a 'cat' subcommand or > > '--format=raw' option to the 'show' subcommand would be better. I'm not > > particular preference - I just wanted the functionality to use in the > > Emacs UI. > > One other approach that I imagined with the json output would be to > simply include all of the MIME parts of all messages directly in the > json-format output from "notmuch show". Does json have any particular > way of encodign a binary blob? If not, should we just have one single > encoding here? (Such as BASE64 within a json string?) I'm sure that JSON could express the blob. There were two reasons that I decided not to include the full message in the JSON output: - some of the parts can be very large, causing Emacs to spend considerably time loading the part (and consume a bunch of memory). This would be particularly noticeable in a thread where many of the messages include large parts - the UI will load all of the parts, even if you've already seen the message. - there are some parts that the UI will probably never display inline usefully (OpenOffice?). For those parts it's quite wasteful to have the UI pull them in. There's obviously a compromise to be had. If we agreed to include text/html parts in the JSON output it would make sense to me - maybe all text/* parts should be there. There are probably others that would be useful. The later 'display all parts' version of notmuch-show is able to use either inline or external content to display parts (it uses that included in the JSON output if present). dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] pull request
On Fri, 02 Apr 2010 09:53:04 +0100, David Edmondson wrote: > The updated changes are on the 'dme-for-cworth' branch now. Thanks for the quick update, David! I've pushed this now. Having played with it a tiny bit, I do think that since the part command always requires a --part option that we might as well just make it part of notmuch show. That is: notmuch show --part=2 id:foo instead of: notmuch part --part=2 id:foo It's no more to type and it keeps our top-level command-set simpler. (Along that same line, I think I'd like to fold "notmuch search-tags" and perhaps "notmuch count" into sub-options of "notmuch search" as well.) But I didn't make the patch block on that. I'm asserting that the notmuch command-line interface is not yet set in stone and that user should expect changes. -Carl pgpzxefyesyKR.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] pull request [was Re: pull request]
On Fri, 02 Apr 2010 15:53:34 -0700, Carl Worth wrote: > On Fri, 02 Apr 2010 09:53:04 +0100, David Edmondson wrote: > > The updated changes are on the 'dme-for-cworth' branch now. > > Thanks for the quick update, David! > > I've pushed this now. Thanks. Here's another set to consider. They are in the 'dme' branch. * commit 94893f25d36aaf43487e111fbfba4f7dae808dd2 | Author: David Edmondson | Date: Tue Mar 23 07:04:34 2010 + | | emacs/notmuch.el: Improve tag highlighting in search mode | | Assume that tags never include an opening bracket, and hence improve | the regular expression used to highlight them. This avoids false | matches where the 'from' address of a thread participant includes an | opening bracket. * commit 4de9f3f09e998d7312be2a1c08526e59bbf135a9 | Author: David Edmondson | Date: Sun Mar 21 09:54:08 2010 + | | emacs/Makefile.local: Use makefile mode * commit f7ecad654fd8d0274fc75833d92117c8e496bcea | Author: David Edmondson | Date: Thu Apr 1 18:36:21 2010 +0100 | | emacs: Move notmuch-show functionality to notmuch-show.el | | To ease the transition to a JSON based implementation of | `notmuch-show', move the current implementation into a separate file. * commit a9590dfb4efc2c05a35948ef4522c362eb788c10 | Author: David Edmondson | Date: Thu Apr 1 11:38:30 2010 +0100 | | Makefile: Add the emacs directory to load-path when compiling dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] pull request
On Fri, 02 Apr 2010 15:53:34 -0700, Carl Worth wrote: > Having played with it a tiny bit, I do think that since the part command > always requires a --part option that we might as well just make it part > of notmuch show. That is: > > notmuch show --part=2 id:foo > > instead of: > > notmuch part --part=2 id:foo > > It's no more to type and it keeps our top-level command-set simpler. As part of having more information about MIME structure in the JSON output (multipart/alternative, for example), I think that we (I, if I get to it first) will need to re-work the `show' implementation somewhat. We should wait until doing that work to merge the `--part' support across. dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] pull request
On Thu, 01 Apr 2010 14:09:57 -0700, Carl Worth wrote: > On Thu, 01 Apr 2010 15:41:03 +0100, David Edmondson wrote: > > Carl, a couple of patches that I'd like you to consider. They are the > > first two on the `dme' branch of git://github.com/dme/notmuch.git. The updated changes are on the 'dme-for-cworth' branch now. > > http://github.com/dme/notmuch/commit/f86254e4509ed02731aa3eaa8541df1f2d11e400 > > > notmuch-show: Add unix and pretty dates to the JSON output > > > > > > Include a 'date_unix' and 'date_pretty' field in the JSON output for > > > each message. 'date_pretty' can be used by a UI implementation, > > > whereas 'date_unix' is useful when scripting. > > With "date_unix" it's easy enough to guess what the value is. But > "date_pretty" is much more ambiguous. I assumed that this would be an > RFC 822 date string, (but then found that it's the relative date that > "notmuch show" is using currently). > > I think I'd rather see that named "date_relative", (or dropped with the > expectation that callers can decide how to format dates on their own). I renamed it to 'date_relative'. Keeping the creation of the relative date strings in one place struck me as a good idea - there will consistency between the two places it is used (search mode and show mode) and if the `notmuch' command is localised the Emacs UI will immediately benefit. > > > The search terms should match only a single message > > > (e.g. id:foo at bar.com). The part number specified refers to the part > > > identifiers output by `notmuch show'. The content of the part is written > > > the stdout with no formatting or identification marks. It is not JSON > > > formatted. > > The above documentation isn't quite complete to me. Is MIME decoding > handled by this or not? Also, the documentation says the search terms > "should match" only one message, but what does the implementation do if > more than one message is matched? It would be good to document that as > well. > > More significantly, this level of documentation needs to be put into the > "notmuch help" output (instead of the placeholder that's there in the > current patch). It also needs to be added to the man page in > notmuch.1. The documentation is updated. Sorry for being lazy. > > The second of these (part) has been the topic of some > > discussion. There's a suggestion that a 'cat' subcommand or > > '--format=raw' option to the 'show' subcommand would be better. I'm not > > particular preference - I just wanted the functionality to use in the > > Emacs UI. > > One other approach that I imagined with the json output would be to > simply include all of the MIME parts of all messages directly in the > json-format output from "notmuch show". Does json have any particular > way of encodign a binary blob? If not, should we just have one single > encoding here? (Such as BASE64 within a json string?) I'm sure that JSON could express the blob. There were two reasons that I decided not to include the full message in the JSON output: - some of the parts can be very large, causing Emacs to spend considerably time loading the part (and consume a bunch of memory). This would be particularly noticeable in a thread where many of the messages include large parts - the UI will load all of the parts, even if you've already seen the message. - there are some parts that the UI will probably never display inline usefully (OpenOffice?). For those parts it's quite wasteful to have the UI pull them in. There's obviously a compromise to be had. If we agreed to include text/html parts in the JSON output it would make sense to me - maybe all text/* parts should be there. There are probably others that would be useful. The later 'display all parts' version of notmuch-show is able to use either inline or external content to display parts (it uses that included in the JSON output if present). dme. -- David Edmondson, http://dme.org
[notmuch] pull request
On Fri, 02 Apr 2010 09:53:04 +0100, David Edmondson wrote: > The updated changes are on the 'dme-for-cworth' branch now. Thanks for the quick update, David! I've pushed this now. Having played with it a tiny bit, I do think that since the part command always requires a --part option that we might as well just make it part of notmuch show. That is: notmuch show --part=2 id:foo instead of: notmuch part --part=2 id:foo It's no more to type and it keeps our top-level command-set simpler. (Along that same line, I think I'd like to fold "notmuch search-tags" and perhaps "notmuch count" into sub-options of "notmuch search" as well.) But I didn't make the patch block on that. I'm asserting that the notmuch command-line interface is not yet set in stone and that user should expect changes. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100402/6f7fe0ee/attachment.pgp>
