Re: Apparently, terms with a common prefix are *not* connected by implicit "OR"

2019-08-20 Thread Rollins, Jameson
On Tue, Aug 20 2019, David Bremner  wrote:
> This will make
> to:a to:b
> and
> from:a from:b
> expand as
> to:a AND to:b
> and
> from:a AND from:b

I can't say if the proposed parser prefix change is correct, but I
support this behavior.

notmuch mailing list

Re: Apparently, terms with a common prefix are *not* connected by implicit "OR"

2019-08-20 Thread David Bremner
Jorge P. de Morais Neto  writes:

> [ I had replied to David Bremner alone so I didn't have to worry about
> private information leakage.  But now I decided to clean the private
> information and reply to the list too. ]
> Em 2019-08-11T20:08:58-0300, David Bremner escreveu:
>> Thanks for the report. As a test, can you try with
>>  $ notmuch count '( 
>> to:"")'
>> I suspect that will work around the problem, which I believe is related
>> to the way that notmuch uses the xapian parser (in order to provide
>> regexp matching for some prefixes). In particular, if I try that with
>> NOTMUCH_DEBUG_QUERY=yes in the environment I can see the implicit OR.

Thanks for the detailed report. There are (at least) two different
things going on (in addition to the strange expansion that I focussed on
before, but seems not to be the most important issue).

One is that the combining with implicit-OR was only intended to work for
"boolean prefixes" like tag:. So this is a documentation bug.

A second thing is due to some implimentation details in notmuch, from:
was being treated (for purposes of combining) as a filter. I think it's
clear we want from: and to: to behave similarly, so I propose the
following patch

diff --git a/lib/ b/lib/
index 24b7ec43..4db1b465 100644
--- a/lib/
+++ b/lib/
@@ -400,7 +400,7 @@ _setup_query_field (const prefix_t *prefix, 
notmuch_database_t *notmuch)
/* we treat all field-processor fields as boolean in order to get the 
raw input */
if (prefix->prefix)
notmuch->query_parser->add_prefix ("", prefix->prefix);
-   notmuch->query_parser->add_boolean_prefix (prefix->name, fp);
+   notmuch->query_parser->add_boolean_prefix (prefix->name, fp, 
 } else {
_setup_query_field_default (prefix, notmuch);

This will make

to:a to:b


from:a from:b

expand as

to:a AND to:b


from:a AND from:b

I don't think it's possible to have

  to:a to:b

expand to

   to:a OR to:b

without also having

   a b

expand to

   a OR b

which I think most people would find surprising.

At the moment I'm not sure I see the benefit of having tag: combine
with implicit OR (other than being slightly easier to document).

notmuch mailing list

Re: segfault using python bindings

2019-08-20 Thread Floris Bruynooghe
On Thu 15 Aug 2019 at 09:28 -0300, David Bremner wrote:

> Floris Bruynooghe  writes:
>> On Wed 14 Aug 2019 at 16:20 -0300, David Bremner wrote:
>>> Can you remind me what the percieved blockers are for merging into the
>>> main notmuch tree? I'm less hung up on python2 compatibility than I used
>>> to be, fwiw. I'd be ok with shipping the old python2 bindings in contrib
>>> for a bit for those who still need/want them, but concentrate our
>>> maintenance effort on the cffi bindings.
>> IIRC it was mostly about how to support transitioning from one API to
>> the other since currently there's no compatibility.  I guess there's
>> nothing stopping one from using both APIs in one codebase though, AFAIK
>> Xapian handles the required locking.  But some of the discussions
>> suggested being able to create a new Message object from an old one etc,
>> allowing you to do more mixing during a transition period.  This is the
>> part that I said is possible but a lot of work and questionable if no
>> one thought they'd be using it.
> Ah right. Well, given the impending removal of python2 from various
> places (e.g. debian testing), I don't think we should be that
> fussy/ambitious.
> I'd propose
> - add the new cffi based bindings, using a distinct name (as you already
>   have).
> - deprecate the old ones
> - port any internal dependencies to the new bindings
> - finally drop the old bindings or move them to contrib/ for people slow
>   in switching.
> I think for the first step we only need a reasonable looking patch
> (series?) from you.

Sounds reasonable, just a quick note that I'm on holiday at the moment
and generally won't be too quick.  But I guess there's no rush.  I was
also trying to improve the docs but got sidetracked at some point.
There should be already reasonable good docstrings though.

For path series what did you have in mind?  One single patch with the
whole lot?  The original history at https:://github/flub/notdb?
Something in between?

I also recall some comments about the naming not being liked much
(notdb).  I'm open to some bikeshedding on the naming if it bothers
people.  I was only aiming for something short but under a different
import name, which are probably still useful features to keep.


notmuch mailing list

FCC and Emacs.el

2019-08-20 Thread Micah Cobb
Hey everyone,

Sorry if this is an elementary question...

I have notmuch, offlineIMAP, and Emacs setup to use with my Gmail account.
I am syncing with my "[Gmail].Sent Mail" folder (that's the folder name in
the remote and local location.

I want to add a +sent tag to my mail (I have a script connected
to offlineimap that does this too), but offlineimap doesn't seem to be
syncing my mail with the Gmail server.

I've seen a lot of people use FCC, but I keep getting an insert error
(unless I set the variable to "nil" in my init.el file. I was trying to get
it to insert "~/Maildir/[Gmail].Sent Mail +sent" but it isn't working, even
if I escape the brackets and space with a slash.

Any idea of what I can do to fix this? I'm loving the setup so far, but
this is an annoying issue.

(Also, I know some people only sync their All Mail folder. I'm not sure how
that works as a two-way sync. I want the effects of my changes to notmuch
tags to affect my Gmail account I log in. Any advice.

notmuch mailing list