<feed xmlns='http://www.w3.org/2005/Atom'>
<title>notmuch/emacs/notmuch.el, branch 0.16</title>
<subtitle>thread-based email index, search, and tagging</subtitle>
<id>https://git.notmuchmail.org/git/notmuch/atom?h=0.16</id>
<link rel='self' href='https://git.notmuchmail.org/git/notmuch/atom?h=0.16'/>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/'/>
<updated>2013-06-25T05:51:37Z</updated>
<entry>
<title>emacs: update search sort order help to match code</title>
<updated>2013-06-25T05:51:37Z</updated>
<author>
<name>Jani Nikula</name>
<email>jani@nikula.org</email>
</author>
<published>2013-06-03T17:56:31Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=c1a42652a173a4bb70ab72388e6ad150d19a2b06'/>
<id>urn:sha1:c1a42652a173a4bb70ab72388e6ad150d19a2b06</id>
<content type='text'>
</content>
</entry>
<entry>
<title>emacs: Fix "no such file or directory" error</title>
<updated>2013-06-12T14:53:27Z</updated>
<author>
<name>Austin Clements</name>
<email>amdragon@MIT.EDU</email>
</author>
<published>2013-06-09T04:45:38Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=88cce8c6a4d898066c0ea4516352ab8749171654'/>
<id>urn:sha1:88cce8c6a4d898066c0ea4516352ab8749171654</id>
<content type='text'>
Occasionally, when the user killed the search buffer when the CLI
process was still running, Emacs would run the
notmuch-start-notmuch-sentinel sentinel twice.  The first call would
process and delete the error output file and the second would fail
with an "Opening input file: no such file or directory, ..." error
when attempting to access the error file.

Emacs isn't supposed to run the sentinel twice.  The reason it does is
rather subtle (and probably a bug in Emacs):

1) When the user kills the search buffer, Emacs invokes
kill_buffer_processes, which sends a SIGHUP to notmuch, but doesn't do
anything else.  Meanwhile, suppose the notmuch search process has
printed some more output, but Emacs hasn't consumed it yet (this is
critical and is why this error only happens sometimes).

2) Emacs gets a SIGCHLD from the dying notmuch process, which invokes
handle_child_signal, which sets the new process status, but can't do
anything else because it's a signal handler.

3) Emacs returns to its idle loop, which calls status_notify, which
sees that the notmuch process has a new status.  This is where things
get interesting.

3.1) Emacs guarantees that it will run process filters on any
unconsumed output before running the process sentinel, so
status_notify calls read_process_output, which consumes the final
output and calls notmuch-search-process-filter.

3.1.1) notmuch-search-process-filter checks if the search buffer is
still alive and, since it's not, it calls delete-process.

3.1.1.1) delete-process correctly sees that the process is already
dead and doesn't try to send another signal, *but* it still modifies
the status to "killed".  To deal with the new status, it calls
status_notify.  Dun dun dun.  We've seen this function before.

3.1.1.1.1) The *recursive* status_notify invocation sees that the
process has a new status and doesn't have any more output to consume,
so it invokes our sentinel and returns.

3.2) The outer status_notify call (which we're still in) is now done
flushing pending process output, so it *also* invokes our sentinel.

This patch addresses this problem at step 3.1.1, where the filter
calls delete-process, since this is a strange and redundant thing to
do anyway.
</content>
</entry>
<entry>
<title>emacs: add `notmuch-archive-tags' cross references in docstrings</title>
<updated>2013-06-02T23:43:14Z</updated>
<author>
<name>David Bremner</name>
<email>bremner@debian.org</email>
</author>
<published>2013-06-02T14:29:17Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=915a707ae482253ea93b13f854153f98dca0d563'/>
<id>urn:sha1:915a707ae482253ea93b13f854153f98dca0d563</id>
<content type='text'>
Several function docstrings refer to behaviour in docstrings that is
really controlled by notmuch-archive-tags. Add cross references, and
replace hardcoding.
</content>
</entry>
<entry>
<title>emacs: replace setq + let with let*</title>
<updated>2013-06-02T23:38:17Z</updated>
<author>
<name>David Bremner</name>
<email>bremner@debian.org</email>
</author>
<published>2013-06-02T14:57:01Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=63782f4023680dd08c88024b50e5e48dfa3f50cd'/>
<id>urn:sha1:63782f4023680dd08c88024b50e5e48dfa3f50cd</id>
<content type='text'>
I found several places where a setq is immediately followed by a let
or a let*. This seems to be the pessimal combination, with the
implicit scope of the setq combined with the extra indentation of the let.
I combined these cases into a single let* which I think is easier to read.
</content>
</entry>
<entry>
<title>emacs: replace (funcall 'foo ...) with (foo ...)</title>
<updated>2013-06-02T14:37:22Z</updated>
<author>
<name>David Bremner</name>
<email>bremner@debian.org</email>
</author>
<published>2013-06-02T12:16:10Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=9de0639126091fa0e48cfde69e3f6044d167a76a'/>
<id>urn:sha1:9de0639126091fa0e48cfde69e3f6044d167a76a</id>
<content type='text'>
I can't see any benefit to the funcall, and it looks like the result
of cut-and-paste from some code that actually used a variable for the
function to call.
</content>
</entry>
<entry>
<title>emacs: Use streaming S-expr parser for search</title>
<updated>2013-06-01T12:00:40Z</updated>
<author>
<name>Austin Clements</name>
<email>amdragon@MIT.EDU</email>
</author>
<published>2013-06-01T00:40:07Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=89efd5717ab26cf626ceb67964b9b4af8820e52c'/>
<id>urn:sha1:89efd5717ab26cf626ceb67964b9b4af8820e52c</id>
<content type='text'>
In addition to being the Right Thing to do, this noticeably improves
the time taken to display the first page of search results, since it's
roughly an order of magnitude faster than the JSON parser.
Interestingly, it does *not* significantly improve the time to
completely fill a large search buffer because for large search
buffers, the cost of creating author invisibility overlays and
inserting text (which slows down with more overlays) dominates.
However, the time required to display the first page of results is
generally more important to the user experience.
</content>
</entry>
<entry>
<title>emacs: Use async process helper for search</title>
<updated>2013-06-01T11:56:16Z</updated>
<author>
<name>Austin Clements</name>
<email>amdragon@MIT.EDU</email>
</author>
<published>2013-06-01T00:40:05Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=08fde50bf3a4c54f6413aff4052e0d84392463f9'/>
<id>urn:sha1:08fde50bf3a4c54f6413aff4052e0d84392463f9</id>
<content type='text'>
Previously, search started the async notmuch process directly.  Now,
it uses `notmuch-start-notmuch'.  This simplifies the process sentinel
a bit and means that we no longer have to worry about errors
interleaved with the JSON output.

We also update the tests of Emacs error handling, since the error
output is now separated from the search results buffer.
</content>
</entry>
<entry>
<title>emacs: Proper error string handling in search sentinel</title>
<updated>2013-05-18T10:50:11Z</updated>
<author>
<name>Austin Clements</name>
<email>amdragon@MIT.EDU</email>
</author>
<published>2013-05-17T20:14:28Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=e63aa66de8d4de43ea9c3b660b951a44dc50bdeb'/>
<id>urn:sha1:e63aa66de8d4de43ea9c3b660b951a44dc50bdeb</id>
<content type='text'>
Apparently Emacs provides a function to stringify errors properly.
Use this in the search sentinel where we have to do our own error
messaging, rather than assuming the first error argument will be the
descriptive string.
</content>
</entry>
<entry>
<title>emacs: possibility to customize the rendering of tags</title>
<updated>2013-03-25T15:38:49Z</updated>
<author>
<name>Damien Cassou</name>
<email>damien.cassou@gmail.com</email>
</author>
<published>2013-03-23T11:29:54Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=b714a808a692a99c1b936be43186a40ab251aeca'/>
<id>urn:sha1:b714a808a692a99c1b936be43186a40ab251aeca</id>
<content type='text'>
This patch extracts the rendering of tags in notmuch-show to
the notmuch-tag file.

This file introduces a `notmuch-tag-formats' variable that associates
each tag to a particular format. This variable can be customized
thanks to the work of Austin Clements. For example,

  '(("unread" (propertize tag 'face '(:foreground "red")))
    ("flagged" (notmuch-tag-format-image tag "star.svg")))

associates a red foreground to the "unread" tag and a star picture to
the "flagged" tag.

Signed-off-by: Damien Cassou &lt;damien.cassou@gmail.com&gt;
</content>
</entry>
<entry>
<title>emacs: Use the minibuffer for CLI error reporting</title>
<updated>2013-01-07T02:47:35Z</updated>
<author>
<name>Austin Clements</name>
<email>amdragon@MIT.EDU</email>
</author>
<published>2013-01-03T21:47:49Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=401dbebd4803477563eff03d719605ed37a8e44d'/>
<id>urn:sha1:401dbebd4803477563eff03d719605ed37a8e44d</id>
<content type='text'>
We recently switched to popping up a buffer to report CLI errors, but
this was too intrusive, especially for transient errors and especially
since we made fewer things ignore errors.  This patch changes this to
display a basic error message in the minibuffer (using Emacs' usual
error handling path) and, if there are additional details, to log
these to a separate error buffer and reference the error buffer from
the minibuffer message.  This is more in line with how Emacs typically
handles errors, but makes the details available to the user without
flooding them with the details.

Given this split, we pare down the basic message and make it more
user-friendly, and also make the verbose message even more detailed
(and more debugging-oriented).
</content>
</entry>
</feed>
