Re: [PATCH v2 4/7] emacs: Use result text properties for search result iteration

Subject: Re: [PATCH v2 4/7] emacs: Use result text properties for search result iteration

Date: Sat, 14 Jul 2012 17:51:56 -0400

To: Jameson Graef Rollins

Cc: notmuch@notmuchmail.org

From: Austin Clements


Quoth Jameson Graef Rollins on Jul 14 at  2:13 pm:
> On Sat, Jul 14 2012, Austin Clements <amdragon@MIT.EDU> wrote:
> > That's strange.  What was the error?
> >
> > I've been testing with
> >    (("date" . "%12s ")
> >     ("count" . "%-7s ")
> >     ("authors" . "%-20s ")
> >     ("subject" . "\n%s ")
> >     ("tags" . "(%s)"))
> > But maybe there are other cases it doesn't handle correctly?
> 
> Hrm.  The error was:
> 
>   error in process filter: wrong type argument: wholenump, -13
> 
> However, that's in my test emacs setup.  It works fine in my normal
> emacs session.  Lets assume this is just a problem with my setup that
> I'll look into.

Interesting.  The "error in process filter" suggests that it is
happening somewhere in the notmuch code under the search process
filter, so it's probably some combination of something unusual in your
environment and this patch.  If you M-x toggle-debug-on-error, will it
drop you into the debugger when this happens?

> The other problem I seem to be running into is that the
> customize-variable interface definitely doesn't handle newlines very
> well.  If I try to add a '\n' in the interface it gets escaped, so I end
> up with:
> 
>      ("subject" . "\\n%s ")
> 
> If I add the '\n' manually in my config, notmuch-search then interprets
> the string correctly and adds newlines to the search results, but then
> the customize-variable interface interprets the newline and adds a
> newline the string field that kind makes the interface a little weird.
> Is there "proper" way to add a newline to a string value in the
> customize-variable interface that I'm not aware of?

I think this is just a sharp corner in customize and there's notmuch
we can do about it.  I believe the "proper" way to enter the newline
directly in customize is to hit C-q C-j (same way you get a raw
newline in any other buffer).  Given that I wouldn't expect anyone to
guess that, though, we could mention this in the defcustom's
docstring.

> In any event, this is in no way a blocker for this patch series.  This
> is all totally tangential.  The patch series is great.
> 
> jamie.

Thread: