notmuch/man, branch 0.17_rc1

version: bump to 0.17~rc1

2013-11-24T00:29:46Z

Various other files are synched using "make update-versions". NEWS has to be hand edited.

man: document notmuch compact --quiet and --backup=DIRECTORY options

2013-11-07T23:16:15Z

notmuch-compact: Add man page

2013-10-10T00:47:39Z

Signed-off-by: Ben Gamari

cli: add --include-html option to notmuch show

2013-08-27T10:57:36Z

For my client, the largest bottleneck for displaying large threads is exporting each html part individually since by default notmuch will not show the json parts. For large threads there can be quite a few parts and each must be exported and decoded one by one. Also, I then have to deal with all the crazy charsets which I can do through a library but is a pain. Therefore, this patch adds an --include-html option that causes the text/html parts to be included as part of the output of show. diff man/man1/notmuch-show.1

man: clarify folder: prefix regarding duplicate files

2013-08-24T09:44:52Z

The results for folder: prefix are a source of recurring confusion.

man: document notmuch count --output=files

2013-08-24T09:44:23Z

Document the notmuch count --output=files option.

man: document notmuch search --duplicate=N

2013-08-24T09:42:30Z

Document the notmuch search --duplicate=N option.

reply: Use RFC 2822/MIME wholly for text format template

2013-08-17T07:06:08Z

Previously, reply's default text format used an odd mix of RFC 2045 MIME encoding for the reply template's body and some made-up RFC 2822-like UTF-8 format for the headers. The intent was to present the headers to the user in a nice, un-encoded format, but this assumed that whatever ultimately sent the email would RFC 2047-encode the headers, while at the same time the body was already RFC 2045 encoded, so it assumed that whatever sent the email would *not* re-encode the body. This can be fixed by either producing a fully decoded UTF-8 reply template, or a fully encoded MIME-compliant RFC 2822 message. This patch does the latter because it is a) Well-defined by RFC 2822 and MIME (while any UTF-8 format would be ad hoc). b) Ready to be piped to sendmail. The point of the text format is to be minimal, so a user should be able to pop up the template in whatever editor they want, edit it, and push it to sendmail. c) Consistent with frontend capabilities. If a frontend has the smarts to RFC 2047 encode the headers before sending the mail, it probably has the smarts to RFC 2047 decode them before presenting the template to a user for editing. Also, as far as I know, nothing automated consumes the reply text format, so changing this should not cause serious problems. (And if anything does still consume this format, it probably gets these encoding issues wrong anyway.)

release: synchronize dates

2013-08-03T11:29:40Z

man pages, NEWS, and debian changelog all hardcode date. Make them hardcode the same date.

version: set new version and release date

2013-07-28T14:28:03Z

These are manually set in version and NEWS, and propagate to the other files via "make update-versions"