<feed xmlns='http://www.w3.org/2005/Atom'>
<title>notmuch/emacs/notmuch-lib.el, branch 0.14</title>
<subtitle>thread-based email index, search, and tagging</subtitle>
<id>https://git.notmuchmail.org/git/notmuch/atom?h=0.14</id>
<link rel='self' href='https://git.notmuchmail.org/git/notmuch/atom?h=0.14'/>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/'/>
<updated>2012-08-12T19:05:08Z</updated>
<entry>
<title>emacs: Fix "not defined at runtime" warning</title>
<updated>2012-08-12T19:05:08Z</updated>
<author>
<name>Austin Clements</name>
<email>amdragon@MIT.EDU</email>
</author>
<published>2012-08-08T21:40:10Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=07b5f97202c840d97bd9f53c62c4192a6b0adf30'/>
<id>urn:sha1:07b5f97202c840d97bd9f53c62c4192a6b0adf30</id>
<content type='text'>
Previously, the Emacs byte compiler produced the warning

    the function `remove-if-not' might not be defined at runtime.

because we only required cl at compile-time (not runtime).  This fixes
this warning by requiring cl at runtime, ensuring that the definition
of remove-if-not is available.
</content>
</entry>
<entry>
<title>emacs: Use text properties instead of overlays for tag coloring</title>
<updated>2012-07-24T12:04:38Z</updated>
<author>
<name>Austin Clements</name>
<email>amdragon@MIT.EDU</email>
</author>
<published>2012-07-21T17:37:06Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=60ebc84945731e37d6cbec19ce51c08c408b49e8'/>
<id>urn:sha1:60ebc84945731e37d6cbec19ce51c08c408b49e8</id>
<content type='text'>
Previously, tag-based search result highlighting was done by creating
an overlay over each search result.  However, overlays have annoying
front- and rear-advancement semantics that make it difficult to
manipulate text at their boundaries, which the next patch will do.
They also have performance problems (creating an overlay is linear in
the number of overlays between point and the new overlay, making
highlighting a search buffer quadratic in the number of results).

Text properties have neither problem.  However, text properties make
it more difficult to apply multiple faces since, unlike with overlays,
a given character can only have a single 'face text property.  Hence,
we introduce a utility function that combines faces into any existing
'face text properties.

Using this utility function, it's straightforward to apply all of the
appropriate tag faces in notmuch-search-color-line.
</content>
</entry>
<entry>
<title>emacs: Implement an incremental JSON parser</title>
<updated>2012-07-12T23:39:28Z</updated>
<author>
<name>Austin Clements</name>
<email>amdragon@MIT.EDU</email>
</author>
<published>2012-07-09T21:42:40Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=889dda3731dcdf779cef347576c5d59d1923d26b'/>
<id>urn:sha1:889dda3731dcdf779cef347576c5d59d1923d26b</id>
<content type='text'>
This parser is designed to read streaming JSON whose structure is
known to the caller.  Like a typical JSON parsing interface, it
provides a function to read a complete JSON value from the input.
However, it extends this with an additional function that
requires the next value in the input to be a compound value and
descends into it, allowing its elements to be read one at a time
or further descended into.  Both functions can return 'retry to
indicate that not enough input is available.

The parser supports efficient partial parsing, so there's no need to
frame the input for correctness or performance.

The bulk of the parsing is still done by Emacs' json.el, so any
improvements or optimizations to that will benefit the incremental
parser as well.

Currently only descending into JSON lists is supported because that's
all we need, but support for descending into JSON objects can be added
in the future.
</content>
</entry>
<entry>
<title>emacs: Suppress warnings about using cl at runtime</title>
<updated>2012-06-03T16:27:07Z</updated>
<author>
<name>Austin Clements</name>
<email>amdragon@MIT.EDU</email>
</author>
<published>2012-03-29T04:33:42Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=44224b6259c82a20f93f19bfab83b817c8009efe'/>
<id>urn:sha1:44224b6259c82a20f93f19bfab83b817c8009efe</id>
<content type='text'>
It was decided in the thread starting at [0] that it is okay for
notmuch to use 'cl runtime functions.  However, by default, these
produce byte compiler warnings.  This suppresses those using
file-local variables.

[0] id:"m262g864dz.fsf@wal122.wireless-pennnet.upenn.edu"
</content>
</entry>
<entry>
<title>emacs: use 'gnus-decoded in notmuch-mm-display-part-inline ()</title>
<updated>2012-05-24T01:29:32Z</updated>
<author>
<name>Tomi Ollila</name>
<email>tomi.ollila@iki.fi</email>
</author>
<published>2012-05-20T16:58:14Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=70ca3444c75beaa693fcac411dd6a2819bd4341e'/>
<id>urn:sha1:70ca3444c75beaa693fcac411dd6a2819bd4341e</id>
<content type='text'>
When mail message is read from emacs, the message structure
obtained may contain parts which have content included
(`text/plain` for example) and other parts where content is not
included (`text/html` for example).

In case content is included, the string is already available in
emacs' internal format and therefore mm-... functions should not
attempt to do further decoding for the data in temp buffer
provided for it.

Currently when reply buffer is created,
notmuch-mm-display-part-inline () is used to provided quoted reply
content. This change makes the mm-... functions called by it use
'gnus-decoded as charset whenever the content is already available.

File .../emacs-23.3/lisp/gnus/mm-uu.el mentions:
"`gnus-decoded' is a fake charset, which means no further decoding."
</content>
</entry>
<entry>
<title>emacs: Correctly quote non-text/plain parts in reply</title>
<updated>2012-05-06T11:48:11Z</updated>
<author>
<name>Adam Wolfe Gordon</name>
<email>awg+notmuch@xvx.ca</email>
</author>
<published>2012-05-05T19:30:37Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=f6c170fabca8f39e74705e3813504137811bf162'/>
<id>urn:sha1:f6c170fabca8f39e74705e3813504137811bf162</id>
<content type='text'>
Quote non-text parts nicely by displaying them with mm-display-part
before calling message-cite-original to quote them. HTML-only emails
can now be quoted correctly. We re-use some code from notmuch-show
(notmuch-show-mm-display-part-inline), which has been moved to
notmuch-lib.el.

Mark the test for this feature as not broken.
</content>
</entry>
<entry>
<title>emacs: Fix two bugs in reply</title>
<updated>2012-04-02T20:45:27Z</updated>
<author>
<name>Adam Wolfe Gordon</name>
<email>awg+notmuch@xvx.ca</email>
</author>
<published>2012-04-01T15:24:21Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=3737ca6e268e6f45353bfbcc4ac4b1d548c5908d'/>
<id>urn:sha1:3737ca6e268e6f45353bfbcc4ac4b1d548c5908d</id>
<content type='text'>
Bug 1: Replying from alternate addresses
----------------------------------------

The reply code was inconsistent in its use of symbols and strings for
header names being passed to message.el functions. This caused the
From header to be lookup up incorrectly, causing an additional From
header to be added with the user's primary address instead of the
correct alternate address.

This is fixed by using symbols everywhere, i.e. never using strings
for header names when interacting with message.el.

This change also removes our use of `mail-header`, since we don't use
it anywhere else, and using assq makes it clear how the header lists
are expected to work.

Bug 2: Duplicate headers in emacs 23.2
--------------------------------------

The message.el code in emacs 23.2 assumes that header names will
always be passed as symbols, so our use of strings caused
problems. The symptom was that on 23.2 (and presumably on earlier
versions) the reply message would end up with two of some headers.

Converting everything to symbols also fixes this issue.
</content>
</entry>
<entry>
<title>emacs: Fix mis-named argument to notmuch-get-bodypart-internal</title>
<updated>2012-03-31T11:27:15Z</updated>
<author>
<name>Austin Clements</name>
<email>amdragon@MIT.EDU</email>
</author>
<published>2012-03-27T01:40:26Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=839a80513a2dc961cab9348bd1442f30611b0fe4'/>
<id>urn:sha1:839a80513a2dc961cab9348bd1442f30611b0fe4</id>
<content type='text'>
Previously, this function took an argument called "message-id", even
though it was a general query, rather than a message ID.  This changes
it to "query".
</content>
</entry>
<entry>
<title>emacs: Escape all message ID queries</title>
<updated>2012-03-31T00:27:03Z</updated>
<author>
<name>Austin Clements</name>
<email>amdragon@MIT.EDU</email>
</author>
<published>2012-03-27T01:37:16Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=ee1180018ee3c772d7ac769222ff9c6940f3c838'/>
<id>urn:sha1:ee1180018ee3c772d7ac769222ff9c6940f3c838</id>
<content type='text'>
This adds a lib function to turn a message ID into a properly escaped
message ID query and uses this function wherever we previously
hand-constructed ID queries.  Wherever this new function is used,
documentation has been clarified to refer to "id: queries" instead of
"message IDs".

This fixes the broken test introduced by the previous patch.
</content>
</entry>
<entry>
<title>emacs: content-type comparison should be case insensitive.</title>
<updated>2012-03-31T00:19:50Z</updated>
<author>
<name>Mark Walters</name>
<email>markwalters1009@gmail.com</email>
</author>
<published>2012-03-25T00:43:28Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=f57ef643026540d6eb20179ccc92e54445a9d21a'/>
<id>urn:sha1:f57ef643026540d6eb20179ccc92e54445a9d21a</id>
<content type='text'>
The function notmuch-match-content-type was comparing content types
case sensitively. Fix it so it tests case insensitively.

This fixes a bug where emacs would not include any body when replying
to a message with content-type TEXT/PLAIN.
</content>
</entry>
</feed>
