On Mon, 21 Mar 2011, Austin Clements wrote:
> On Fri, Mar 11, 2011 at 3:58 AM, Michal Sojka wrote:
> > Additionally, I'd suggest to support value range queries for dates with
> > ".." syntax. Besides that some users may relay on this syntax, I use
> > date searches a lot and with custom query
On Mon, 21 Mar 2011, Austin Clements wrote:
On Fri, Mar 11, 2011 at 3:58 AM, Michal Sojka sojk...@fel.cvut.cz wrote:
Additionally, I'd suggest to support value range queries for dates with
.. syntax. Besides that some users may relay on this syntax, I use
date searches a lot and with custom
On Fri, Mar 11, 2011 at 3:58 AM, Michal Sojka wrote:
> On Fri, 11 Mar 2011, Carl Worth wrote:
>> I've finally had a chance to start looking at this.
>
> [...]
>
>> 1. For "new" search features (ADJ,NEAR,etc.) I do not have a strong
>> ? ?interest in compatibility with Xapian.
>>
>> ? ?I was very
I haven't made any changes to the query parser yet, but I wanted to
reply to your questions. (I might not get a chance to change things
for a while; I spent this weekend catching my breath and dealing with
all of the things I punted over the past few weeks and tomorrow it's
back to a different
I haven't made any changes to the query parser yet, but I wanted to
reply to your questions. (I might not get a chance to change things
for a while; I spent this weekend catching my breath and dealing with
all of the things I punted over the past few weeks and tomorrow it's
back to a different
On Fri, Mar 11, 2011 at 3:58 AM, Michal Sojka sojk...@fel.cvut.cz wrote:
On Fri, 11 Mar 2011, Carl Worth wrote:
I've finally had a chance to start looking at this.
[...]
1. For new search features (ADJ,NEAR,etc.) I do not have a strong
interest in compatibility with Xapian.
I was
On Fri, 11 Mar 2011, Carl Worth wrote:
> I've finally had a chance to start looking at this.
[...]
> 1. For "new" search features (ADJ,NEAR,etc.) I do not have a strong
>interest in compatibility with Xapian.
>
>I was very careful when I wrote the documentation for the notmuch
>
On Fri, 11 Mar 2011, Carl Worth wrote:
I've finally had a chance to start looking at this.
[...]
1. For new search features (ADJ,NEAR,etc.) I do not have a strong
interest in compatibility with Xapian.
I was very careful when I wrote the documentation for the notmuch
search
Quoth Carl Worth on Mar 10 at 6:21 pm:
> On Fri, 28 Jan 2011 21:26:03 -0500, Austin Clements
> wrote:
> > unlocked. Here's the fix. cworth, what's the most convenient way for
> > me to slip this in to the patch series?
>
> I'd most prefer a rebased branch including the fix, along with an
On Thu, 10 Mar 2011 21:47:30 -0500, Austin Clements wrote:
> Yes, qparser-3 is ready for you, and has this fix folded in to it (see
> id:20110202050336.GB28537 at mit.edu).
Thanks.
I've finally had a chance to start looking at this.
The first thing that caught my eye was this question:
> +/*
> What do you think?
>
> Of course, I still want to have email so that everyone can follow along
> at home, and it's easy to reply for patch review, etc.
Hey, Carl. I would say you should just wait for an email to the list
that says explicitly that "branch X at remote Y is ready to be merged".
On Fri, 28 Jan 2011 21:26:03 -0500, Austin Clements wrote:
> unlocked. Here's the fix. cworth, what's the most convenient way for
> me to slip this in to the patch series?
I'd most prefer a rebased branch including the fix, along with an email
sent to me, (giving either the branch-name to pull
On Fri, 28 Jan 2011 21:26:03 -0500, Austin Clements amdra...@mit.edu wrote:
unlocked. Here's the fix. cworth, what's the most convenient way for
me to slip this in to the patch series?
I'd most prefer a rebased branch including the fix, along with an email
sent to me, (giving either the
Quoth Carl Worth on Mar 10 at 6:21 pm:
On Fri, 28 Jan 2011 21:26:03 -0500, Austin Clements amdra...@mit.edu wrote:
unlocked. Here's the fix. cworth, what's the most convenient way for
me to slip this in to the patch series?
I'd most prefer a rebased branch including the fix, along with
On Thu, 10 Mar 2011 21:47:30 -0500, Austin Clements amdra...@mit.edu wrote:
Yes, qparser-3 is ready for you, and has this fix folded in to it (see
id:20110202050336.gb28...@mit.edu).
Thanks.
I've finally had a chance to start looking at this.
The first thing that caught my eye was this
Looks like I managed to remove the line that deletes (and thus closes
and unlocks) the Xapian::Database object in a bout of overzealous code
removal. The consequence was exactly what you suspected; there was a
brief window after notmuch had exited before the database actually got
unlocked.
This should most definitely not happen. I'll look in to it.
On Fri, Jan 28, 2011 at 5:18 AM, Michal Sojka wrote:
> Hi Austin,
>
> when I switched to using your custom query parser I started experiencing
> "Unable to get write lock" errors when I run my initial tagging script.
> I thought that
Hi Austin,
when I switched to using your custom query parser I started experiencing
"Unable to get write lock" errors when I run my initial tagging script.
I thought that this was because I run the script while processing the
mail in Emacs, but today I realized that this happens even without
This should most definitely not happen. I'll look in to it.
On Fri, Jan 28, 2011 at 5:18 AM, Michal Sojka sojk...@fel.cvut.cz wrote:
Hi Austin,
when I switched to using your custom query parser I started experiencing
Unable to get write lock errors when I run my initial tagging script.
I
Looks like I managed to remove the line that deletes (and thus closes
and unlocks) the Xapian::Database object in a bout of overzealous code
removal. The consequence was exactly what you suspected; there was a
brief window after notmuch had exited before the database actually got
unlocked.
20 matches
Mail list logo
