search for: tethera

David Bremner <david at tethera.net> writes: >> Here's why it would freeze: >> >> I have a post-new hook that runs a Python script. Depending on >> whether the new email it is processing matches a rule I have, >> it will fire off an email to the sender using the SMTP library >> in...

Franz Fellner <alpine.art.de at gmail.com> writes: > I also suffer from bad performance of notmuch new. I used notmuch > some years ago and notmuch new always felt instantanious. Had to stop > using it because internet was too slow to sync my mails :/ Now (with > better internet and a completely new setup using mbsync) indexing one > mail takes at least 10 seconds,

Ioan-Adrian Ratiu <adi at adirat.com> writes: > I'd like to add a feature to quickly work with mail file sizes > because using custom scripts / external programs which parse > maildir contents is slow, and non-intuitive, especially since > notmuch does incremental parsing and has such a nice emacs UI. I just remembered (and olly confirmed) that there is some work in

....FLAG_DEFAULT|qp.FLAG_BOOLEAN_ANY_CASE)) 'Query(Snot at 1)' Note that I'm using 1.4.7, and from your output I believe you're not (the * in the query description I believe doesn't happen in those situations any more). J > On 29 Sep 2018, at 23:09, David Bremner <david at tethera.net> wrote: > > > Today we noticed that keywords can't be searched as prefixed terms. Or > that's what it looks like anyway. I tested and, or, and not. > > ╰─% NOTMUCH_DEBUG_QUERY=y notmuch search 'subject:"and"' > Query string is: > subject:&...

On Sun, Sep 30, 2018 at 09:50:30AM +0100, James Aylett wrote: > Note that I'm using 1.4.7, and from your output I believe you're not > (the * in the query description I believe doesn't happen in those > situations any more). 1.4.4 and later eliminate redundant 0 scaling factors, but this one isn't actually redundant: > > Query(((Tmail AND 0 * XSUBJECTnot at 1)

Today we noticed that keywords can't be searched as prefixed terms. Or that's what it looks like anyway. I tested and, or, and not. ╰─% NOTMUCH_DEBUG_QUERY=y notmuch search 'subject:"and"' Query string is: subject:"and" notmuch search: A Xapian exception occurred A Xapian exception occurred parsing query: Syntax: <expression> AND <expression> Query

"Kirill A. Shutemov" <kirill at shutemov.name> writes: > Hello, > > I found that on particular queries notmuch return different results if run > the query few times. Re-initialing the query or db doesn't help. > > I've attached test case along with corpus of messages. > > Unpack the archive and run `make' there. It will initialize the notmuch

Mueen Nawaz <mueen at nawaz.org> writes: > After a lot of poking around, I figured out the problem, and this may be > of interest to the developers (although not sure if it is a xapian issue > or a notmuch issue). > > Here's why it would freeze: > > I have a post-new hook that runs a Python script. Depending on whether > the new email it is processing matches a

io <io at ooeeeoo.com> writes: > what xapian 'indexing system' did was to index the entire sentence > 'xxx_yyy' and you will not be able to find any sentence which contain > the word 'yyy'? I'm curious that you refer to xxx_yyy as a sentence. In the contexts I am familiar with, the point of _ is to join things together into one word (or one

Olly Betts <olly at survex.com> writes: > The development version of Xapian supports both `*` and `?` glob-style > wildcards in any position. > > You can enable them for the QueryParser using FLAG_WILDCARD_MULTI, > FLAG_WILDCARD_SINGLE or FLAG_WILDCARD_GLOB (the last one is just the > first two combined). I see FLAG_FUZZY as well, supporting edit distance. Sounds like

Olly Betts <olly at survex.com> writes: > On Tue, Jan 05, 2016 at 08:43:13AM -0400, David Bremner wrote: >> Olly Betts <olly at survex.com> writes: >> >> > To achieve this with synonyms in a configurable way you'd need to >> > rewrite the synonyms in the database to match the current configuration, >> > so it's not as dynamic as the

Olly Betts <olly at survex.com> writes: > A better option for this is probably a FieldProcessor - you set one for > a prefix and the it gets passed the value and returns a Query object > for it. E.g. in lua (where you can just pass an anon function for the > FieldProcessor - we ought to support C++11 lambdas for such things): By the way, is there an online version of the

Antoine Beaupré <anarcat at orangeseeds.org> writes: > Hmm... but if I understand correctly, that's one part of the story: I > could get that error and not have the problem with `notmuch show`. Does > that *also* resolve the issue with email loops? I don't think so, no. d

Javier Garcia <javiertury at gmail.com> writes: > Unfortunately I can't share my emails without the approval of other > parties. The minimum subsets that trigger the error are in the range of > 1000-5000 mails, so asking each and everyone of them is out of my reach. > I tried to replicate the problem using just spam folders without success. > > The following is a solid

Gregor Zattler <telegraph at gmx.net> writes: > Hi notmuch developers, > > I also had this database corruption, I waited for the fix to land > in notmuch 0.26.2, build it, moved the xapian directory away, did > a notmuch new and restored the tags from a dump. But the problem > remains: > > ~$ xapian-check ~/Mail/.notmuch/xapian > docdata: > blocksize=8K

Daniel Barlow <dan at telent.net> writes: > There are a number of ways this is currently insecure but the particular > one I want to ask about today is running the notmuch cli commands with > user-supplied arguments and whether there are any particular gotchas in > doing so? I am reasonably sure that my code to invoke notmuch(1) is > calling execve(2) without invoking

Mueen Nawaz <mueen at nawaz.org> writes: > > DATABASE = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE) OK. So your code is locking the database, and never unlocking it (because of the hang). So that part is at least not mysterious. > I can think of two experiments: I was thinking more along the lines of something that could be part of the notmuch test suite, i.e. run in

Olly Betts <olly at survex.com> writes: > > FWIW, I also couldn't reproduce this (I tried with quest and 1.4.7): > > $ quest -psubject:S -fdefault,boolean_any_case 'subject:"and"' > Parsed Query: Query(Sand at 1) > Ah, OK, it must have something to do with the way that notmuch is using field processors. And I see now that the following code (from

Thomas Schwinge <thomas at schwinge.name> writes: > sizes?). Doing some light (read-only!) testing, it seems to work fine to > access the old 32-bit built Xapian "chert" database with 64-bit > notmuch/Xapian. Is that (a) generally safe and expected to work fine, > (b) there may be issues, or (c) don't do that, or don't know? > IIRC, Olly previously

Olly Betts <olly at survex.com> writes: > Incidentally, if you're actually aiming to match different forms of a > name (Peter vs Pete, Ann vs Anne vs Annette) then you might find the > synonym feature a better option than wildcarding. > What about a custom stemmer? d