[PATCH v3 0/6] Make Emacs search use sexp format
Jameson Graef Rollins
jrollins at finestructure.net
Sun Jun 2 08:51:14 PDT 2013
On Sat, Jun 01 2013, David Bremner <david at tethera.net> wrote:
> Austin Clements <amdragon at MIT.EDU> writes:
>
>> This is v3 of id:1369934016-22308-1-git-send-email-amdragon at mit.edu.
>> This tweaks the shell invocation as suggested by Tomi and fixes two
>> comment typos pointed out by Mark. It also adds a NEWS patch. I'm
>> going to go ahead and mark this ready because of Tomi's and Mark's
>> reviews of v2.
>
> The first 5 I pushed. The NEWS patch has a conflict.
I'm very happy to see the long-coming sexp handling working here. Good
work, folks, particularly to Austin for getting the awesome asynchronous
processing stuff working. Searches are now definitely noticeably
faster.
I am, however, seeing a couple of issues that we might want to address.
* Killing a search buffer that is still in the process of being filled
causes errors to be thrown. I'm seeing both of the following
intermittently:
[Sun Jun 2 08:26:40 2013]
notmuch exited with status killed
command: notmuch search --format\=sexp --format-version\=1 --sort\=newest-first to\:jrollins
exit signal: killed
[Sun Jun 2 08:32:26 2013]
notmuch exited with status hangup
command: notmuch search --format\=sexp --format-version\=1 --sort\=newest-first to\:jrollins
exit signal: hangup
This is somewhat understandable, as the notmuch binary exits with an
error if it hasn't finished dumping the output, but given how common
this particular scenario is I think we should try to avoid throwing
errors in this circumstance. I wonder if we shouldn't just modify the
binary to not return non-zero if it was manually killed while
processing the output, or at least special-case the particular error
caused by manually killing the search.
* The next thing I'm seeing is this:
Opening input file: no such file or directory, /home/jrollins/tmp/nmerr5390CAY
I'm not exactly sure what causes this error, but it looks to me like
the temporary error file was removed before we were finished with it.
* Finally, something happened that caused *12,000* of the following lines
to be sent to the *Notmuch errors* buffer:
A Xapian exception occurred performing query: The revision being read has been discarded - you should call Xapian::Database::reopen() and retry the operation
Again, this was related to killing a search buffer that was still
being filled. I'm pretty sure the database was not modified during
this process.
Let me know if I can help provide any more info.
jamie.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130602/045a493f/attachment.pgp>
More information about the notmuch
mailing list