Re: [PATCH v3 0/6] Make Emacs search use sexp format

[Jameson Graef Rollins <jrollins@finestructure.net>]

[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]

On Sat, Jun 01 2013, David Bremner <david@tethera.net> wrote:
> Austin Clements <amdragon@MIT.EDU> writes:
>
>> This is v3 of id:1369934016-22308-1-git-send-email-amdragon@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.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]