Currently this code uses a bitmap indexed by docid as a simple, fast
set structure. This is quite memory-efficient if the docid space is
dense, even if the largest docid is quite large. Is there a danger
that the docid space will be large and sparse? Is it worth replacing
this with a smarter bit
Hi,
I just realized that GMime is not robust to some broken email addresses
sent by broken email clients. I received a mail, with the to field being
.
The email client (Exchange) had forgotten to put a "" around
".", which is necessary because `.' is a special character, and
th
Update author order in Emacs tests to reflect correct order.
---
test/author-order | 10
test/emacs |4 +-
.../emacs.expected-output/notmuch-hello-view-inbox | 26 ++--
.../emacs.expected-outp
This reduces thread search's 1+2t Xapian queries (where t is the
number of matched threads) to 1+t queries and constructs exactly one
notmuch_message_t for each message instead of 2 to 3.
notmuch_query_search_threads eagerly fetches the docids of all
messages matching the user query instead of lazi
Use varying dates in the test messages to test the order authors are
listed in. Add tests with repeated author names and unusual date
ordering. Most of these are broken at the moment, but will be fixed
shortly.
---
test/author-order | 30 ++
1 files changed, 26 inse
Make sure to close the subtest for test_expect_equal_failure, just
like in test_expect_equal.
---
test/test-lib.sh |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
mode change 100644 => 100755 test/test-lib.sh
diff --git a/test/test-lib.sh b/test/test-lib.sh
old mode 100644
new mode 1
Hi,
I just realized that GMime is not robust to some broken email addresses
sent by broken email clients. I received a mail, with the to field being
.
The email client (Exchange) had forgotten to put a "" around
".", which is necessary because `.' is a special character, and
th
The removed expressions, which were used to ensure that citations were
both preceded and followed by a blank line, were poorly implemented
and caused a regexp stack overflow on messages more than a few
thousand lines long.
---
Carl, I was not able to find a version of the regular expressions that
Incremental search does not match strings that span a
visible/invisible boundary. This results in failure to correctly
isearch for authors in `notmuch-search' mode if the name of the author
is split between the visible and invisible components of the authors
string. To avoid this, attempt to trunca
Use varying dates in the test messages to test the order authors are
listed in. Add tests with repeated author names and unusual date
ordering. Most of these are broken at the moment, but will be fixed
shortly.
---
test/author-order | 30 ++
1 files changed, 26 inse
Make sure to close the subtest for test_expect_equal_failure, just
like in test_expect_equal.
---
test/test-lib.sh |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
mode change 100644 => 100755 test/test-lib.sh
diff --git a/test/test-lib.sh b/test/test-lib.sh
old mode 100644
new mode 1
Update author order in Emacs tests to reflect correct order.
---
test/author-order | 10
test/emacs |4 +-
.../emacs.expected-output/notmuch-hello-view-inbox | 26 ++--
.../emacs.expected-outp
This reduces thread search's 1+2t Xapian queries (where t is the
number of matched threads) to 1+t queries and constructs exactly one
notmuch_message_t for each message instead of 2 to 3.
notmuch_query_search_threads eagerly fetches the docids of all
messages matching the user query instead of lazi
The removed expressions, which were used to ensure that citations were
both preceded and followed by a blank line, were poorly implemented
and caused a regexp stack overflow on messages more than a few
thousand lines long.
---
Carl, I was not able to find a version of the regular expressions that
Incremental search does not match strings that span a
visible/invisible boundary. This results in failure to correctly
isearch for authors in `notmuch-search' mode if the name of the author
is split between the visible and invisible components of the authors
string. To avoid this, attempt to trunca
On Tue, Nov 16, 2010 at 22:42, Daniel Kahn Gillmor
wrote:
> On 11/16/2010 03:37 PM, Daniel Kahn Gillmor wrote:
>> On 11/16/2010 03:26 PM, Ciprian Dorin, Craciun wrote:
>>> ? ? So in the light of the above quoted "glitches", my question is:
>>> due to the small chance of a power loss happening righ
On Tue, Nov 16, 2010 at 22:37, Daniel Kahn Gillmor
wrote:
> On 11/16/2010 03:26 PM, Ciprian Dorin, Craciun wrote:
>> ? ? P.S.: I say "pseudo" atomic because only the rename is atomic,
>> thus in order to override file `a` for the target file `b` which
>> exists, we must execute two **non-atomic**
17 matches
Mail list logo
