Threaded view would do annoying scroll

2019-08-21 Thread Sanel Zukan
Hi, I'm using Emacs 26.2 and Notmuch 0.28.2 and I noticed that after updating Emacs to 26.2, notmuch would start doing annoying (auto)scroll inside thraded view opened message, probably trying to center the message. The search is done calling `notmuch-search`. Anyone got similar behavior or

Threaded view would do annoying scroll

2019-08-21 Thread Sanel Zukan
Hi, I'm using Emacs 26.2 and Notmuch 0.28.2 and I noticed that after updating Emacs to 26.2, notmuch would start doing annoying (auto)scroll inside thraded view opened message, probably trying to center the message. The search is done calling `notmuch-search`. Anyone got similar behavior or

Re: segfault using python bindings

2019-08-21 Thread Daniel Kahn Gillmor
On Tue 2019-08-20 19:20:30 +0200, Floris Bruynooghe wrote: > 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

Re: regex [X-Z] with non-ascii char returns different results from (X|Y|Z)

2019-08-21 Thread David Bremner
"yury.t" writes: > Some regular expression returns incorrect results if the pattern > contains multibyte characters in square brackets. The following > bracket expression matches subjects not starting with `[1-9]` and > returns more results than the parenthesis expression. We rely on POSIX.2

regex [X-Z] with non-ascii char returns different results from (X|Y|Z)

2019-08-21 Thread yury.t
Some regular expression returns incorrect results if the pattern contains multibyte characters in square brackets. The following bracket expression matches subjects not starting with `[1-9]` and returns more results than the parenthesis expression. (Please note that digits are full width,

[PATCH 1/3] test: add known broken tests for from: and subject:

2019-08-21 Thread David Bremner
Given we want 'a b' to parse as 'a AND b', then for any probabilistic (free text) prefix foo:, we should also get 'foo:a foo:b' expanding to 'foo:a AND foo:b'. Currently this is not true due to the implimentation of regex fields. --- test/T760-implicit-operators.sh | 28

[PATCH 2/3] lib: introduce N_F_GROUP and use it to fix implicit AND for from:

2019-08-21 Thread David Bremner
This needs tests for every prefix and documentation --- lib/database-private.h | 1 + lib/database.cc | 23 +-- test/T760-implicit-operators.sh | 4 ++-- 3 files changed, 20 insertions(+), 8 deletions(-) diff --git a/lib/database-private.h

[PATCH 3/3] WIP/test: extend field grouping tests

2019-08-21 Thread David Bremner
--- test/T760-implicit-operators.sh | 60 +++-- 1 file changed, 49 insertions(+), 11 deletions(-) diff --git a/test/T760-implicit-operators.sh b/test/T760-implicit-operators.sh index 1a6ba61f..438f766f 100755 --- a/test/T760-implicit-operators.sh +++

WIP: fix implicit operators

2019-08-21 Thread David Bremner
I'm posting this for feedback. I did all the tests that were easy, but things like threads and attachments will take more effort to test. for probabilistic prefixes, we are basically stuck with AND. For boolean prefixes, we have the choice. Generally I tried to follow the Xapian convention that