<feed xmlns='http://www.w3.org/2005/Atom'>
<title>notmuch/emacs/notmuch-lib.el, branch 0.22</title>
<subtitle>thread-based email index, search, and tagging</subtitle>
<id>https://git.notmuchmail.org/git/notmuch/atom?h=0.22</id>
<link rel='self' href='https://git.notmuchmail.org/git/notmuch/atom?h=0.22'/>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/'/>
<updated>2016-04-16T11:24:42Z</updated>
<entry>
<title>emacs: Fix packaging</title>
<updated>2016-04-16T11:24:42Z</updated>
<author>
<name>Chunyang Xu</name>
<email>xuchunyang.me@gmail.com</email>
</author>
<published>2016-04-13T07:58:47Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=0cf457b73b4b666314d1a09ac3e31bd0fa2346a6'/>
<id>urn:sha1:0cf457b73b4b666314d1a09ac3e31bd0fa2346a6</id>
<content type='text'>
Refer to (info "(elisp) Library Headers") for package conventions.
</content>
</entry>
<entry>
<title>emacs: Allow part preferences to depend on message content.</title>
<updated>2016-04-09T19:17:20Z</updated>
<author>
<name>David Edmondson</name>
<email>dme@dme.org</email>
</author>
<published>2016-04-03T16:04:38Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=f0881394bd8bec4af8ddedf0a128648a3a4e2127'/>
<id>urn:sha1:f0881394bd8bec4af8ddedf0a128648a3a4e2127</id>
<content type='text'>
Currently the preference for which sub-part of a multipart/alternative
part is shown is global. Allow to the user to override the settings on a
per-message basis by providing the ability to call a function that has
access to the message to return the discouraged type list.

The original approach is retained as the default.
</content>
</entry>
<entry>
<title>emacs: Improve the acquisition of text parts.</title>
<updated>2016-03-27T20:44:24Z</updated>
<author>
<name>David Edmondson</name>
<email>dme@dme.org</email>
</author>
<published>2016-03-08T17:12:59Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=c41d0db077f295c92b01b69ed001afa233b7d0f0'/>
<id>urn:sha1:c41d0db077f295c92b01b69ed001afa233b7d0f0</id>
<content type='text'>
`notmuch-get-bodypart-text' assumed that it is always possible to
acquire text/* parts via the sexp output format. This is not true if the
part in question has a content type of application/octet-stream but is
being interpreted as text/* based on the extension of the part filename.

Rework `notmuch-get-bodypart-text' to use the raw output format to
address this and make the implementation common with that of
`notmuch-get-bodypart-binary'.
</content>
</entry>
<entry>
<title>Merge branch 'release'</title>
<updated>2015-11-23T12:40:40Z</updated>
<author>
<name>David Bremner</name>
<email>david@tethera.net</email>
</author>
<published>2015-11-23T12:40:40Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=bceb6516cee170d3ad4b620826d48e90f05a12b1'/>
<id>urn:sha1:bceb6516cee170d3ad4b620826d48e90f05a12b1</id>
<content type='text'>
Merge bugfixes applied directly to release
</content>
</entry>
<entry>
<title>emacs: poll: return useful errors when poll fails.</title>
<updated>2015-11-23T12:37:19Z</updated>
<author>
<name>Mark Walters</name>
<email>markwalters1009@gmail.com</email>
</author>
<published>2015-10-28T18:28:39Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=4c7a592d49266d588e717c232bc7aacbe4e16bfb'/>
<id>urn:sha1:4c7a592d49266d588e717c232bc7aacbe4e16bfb</id>
<content type='text'>
Previously poll called from emacs would fail silently. This makes it
return a useful error message.

In the non-deprecated case of notmuch new and appropriate hooks, it
uses notmuch-call-notmuch-process which gives an error and
additionally puts the stdout/stderr etc in the *Notmuch errors*
buffer.

In the deprecated case of a custom poll script it only returns an
error message.

Commit based on a bug report, and a potential fix, by Ketil Malde.
</content>
</entry>
<entry>
<title>Emacs: Add address completion mechanism implemented in elisp</title>
<updated>2015-10-27T11:01:05Z</updated>
<author>
<name>Michal Sojka</name>
<email>sojkam1@fel.cvut.cz</email>
</author>
<published>2015-10-26T23:22:48Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=89f78d38c1f7c9416e5bd9521dd694bb4f90572f'/>
<id>urn:sha1:89f78d38c1f7c9416e5bd9521dd694bb4f90572f</id>
<content type='text'>
Currently, notmuch has an address completion mechanism that requires
external command to provide completion candidates. This commit adds a
completion mechanism inspired by https://github.com/tjim/nevermore,
which is implemented in Emacs lisp only.

The preexisting address completion mechanism, activated by pressing
TAB on To/Cc lines, is extended to use the new mechanism when
notmuch-address-command to 'internal, which is the new default.

The core of the new mechanism is the function notmuch-address-harvest,
which collects the completion candidates from the notmuch database and
stores them in notmuch-address-completions variable. The address
harvesting can run either synchronously (same as with the previous
mechanism) or asynchronously. When the user presses TAB for the first
time, synchronous harvesting limited to user entered text is performed.
If the entered text is reasonably long, this operation is relatively
fast. Then, asynchronous harvesting over the full database is triggered.
This operation may take long time (minutes on rotating disk). After it
finishes, no harvesting is normally performed again and subsequent
completion requests use the harvested data cached in memory. Completion
cache is updated after 24 hours.

Note that this commit restores (different) completion functionality for
users when the user used external command named "notmuch-addresses",
i.e. the old default.  The result will be that the user will use
the new mechanism instead of this command. I believe that many users may
not even recognize this because the new mechanism works the same as
http://commonmeasure.org/~jkr/git/notmuch_addresses.git and perhaps also
as other commands suggested at
http://notmuchmail.org/emacstips/#address_completion.

[This feature was significantly improved by David Bremner and Mark Walters]
</content>
</entry>
<entry>
<title>emacs: prefer notmuch-emacs-version in User-Agent: header</title>
<updated>2015-08-04T18:56:38Z</updated>
<author>
<name>Tomi Ollila</name>
<email>tomi.ollila@iki.fi</email>
</author>
<published>2015-08-02T14:48:14Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=3c1eea5646fcf33d66acb874d82f3518a75c24de'/>
<id>urn:sha1:3c1eea5646fcf33d66acb874d82f3518a75c24de</id>
<content type='text'>
Now that we have `notmuch-emacs-version' defined in notmuch emacs MUA
use that as a part of User-Agent: header to provide more accurate
version information when sending emails.

In case some incomplete installation of notmuch emacs MUA is used and
`notmuch-emacs-version' is defined as "unknown" then fall back to ask
version info from cli (as it used to be before this commit).

Requiring notmuch-version[.elc] and if that is missing setting
"fallback" notmuch-emacs-version (to "unknown") was moved from
notmuch.el to notmuch-lib.el as notmuch-mua.el (which provides
User-Agent: information) require's the latter.
</content>
</entry>
<entry>
<title>emacs: renamed function notmuch-version to notmuch-cli-version</title>
<updated>2015-08-04T18:56:28Z</updated>
<author>
<name>Tomi Ollila</name>
<email>tomi.ollila@iki.fi</email>
</author>
<published>2015-08-02T14:48:13Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=0c565fa29fc29f74209d4343e2fc88f3b8008aaa'/>
<id>urn:sha1:0c565fa29fc29f74209d4343e2fc88f3b8008aaa</id>
<content type='text'>
As it asks `notmuch` binary for its version number.
</content>
</entry>
<entry>
<title>emacs: Support caching in notmuch-get-bodypart-{binary,text}</title>
<updated>2015-01-25T17:39:13Z</updated>
<author>
<name>Austin Clements</name>
<email>amdragon@mit.edu</email>
</author>
<published>2015-01-24T21:17:00Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=3687418526b155668578c1d70ccd6d9b63de2200'/>
<id>urn:sha1:3687418526b155668578c1d70ccd6d9b63de2200</id>
<content type='text'>
(The actual code change here is small, but requires re-indenting
existing code.)
</content>
</entry>
<entry>
<title>emacs: Return unibyte strings for binary part data</title>
<updated>2015-01-25T17:39:13Z</updated>
<author>
<name>Austin Clements</name>
<email>amdragon@mit.edu</email>
</author>
<published>2015-01-24T21:16:59Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=9d19f325f5a0879e2f646e83e59595d5cb345de3'/>
<id>urn:sha1:9d19f325f5a0879e2f646e83e59595d5cb345de3</id>
<content type='text'>
Unibyte strings are meant for representing binary data.  In practice,
using unibyte versus multibyte strings affects *almost* nothing.  It
does happen to matter if we use the binary data in an image descriptor
(which is, helpfully, not documented anywhere and getting it wrong
results in opaque errors like "Not a PNG image: &lt;giant binary spew
that is, in fact, a PNG image&gt;").
</content>
</entry>
</feed>
