* to be in?
--
Austin Clements MIT/'06/PhD/CSAIL
amdra...@mit.edu http://web.mit.edu/amdragon
Somewhere in the dream we call reality you will find me,
searching for the reality we call dreams
Quoth David Edmondson on Nov 16 at 4:58 pm:
On Tue, 16 Nov 2010 11:18:43 -0500, Austin Clements amdra...@mit.edu wrote:
[1] Except for 2 emacs tests that depend on author order. What order
are matched authors *supposed* to be in?
In IRC cworth confirmed that he considered the current
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 ++--
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
Unfortunately, expansion *is* performed by the remote shell, which is why
your shell quoting approach works (and is necessary). There's really no way
around this, since the ssh client simply joins all of its trailing arguments
with spaces and sends this single string to the ssh server, which
Out of curiosity, why not simply use SSH control mastering? You could even
make that part of the standard remote notmuch script, without requiring
the user to change anything in their ssh configuration. This should be just
as fast as a remote notmuch shell, but retains the ability to run
What about
notmuch count query1; notmuch count query2; ...
all as a single command issued by notmuch-hello? That should give exactly
the same output, but eliminates the network round-trips without special
support from count. It would be interesting to see how this compares with
your modified
Quoth Carl Worth on Dec 07 at 5:19 pm:
On Wed, 17 Nov 2010 14:28:26 -0500, Austin Clements amdra...@mit.edu wrote:
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
Remove the repeated sizeof (doc_ids-bitmap[0]) that bothered cworth
by instead defining macros to compute the word and bit offset of a
given bit in the bitmap.
Don't require the caller of _notmuch_doc_id_set_init to pass in a
correct bound; instead compute it from the array. This simplifies the
This replaces the guts of the filename list and tag list, making those
interfaces simple iterators over the generic string list. The
directory, message filename, and tags-related code now build generic
string lists and then wraps them in specific iterators. The real wins
come in later patches,
Replace _notmuch_convert_tags with this and simplify
_create_filenames_for_terms_with_prefix. This will also come in handy
shortly to get the message file name list.
---
lib/database-private.h | 16 +++-
lib/database.cc| 36 ++--
Even if the caller never uses the file names, there is little cost to
simply fetching the file name terms. However, retrieving the full
paths requires additional database work, so the expansion from terms
to full paths is performed lazily.
This also simplifies clearing the filename cache, since
Now each caller of notmuch_message_get_tags only gets a new iterator,
instead of a whole new list. In principle this could cause problems
with iterating while modifying tags, but through the magic of talloc
references, we keep the old tag list alive even after the cache in the
message object is
Short of full header indexing, wouldn't a better way to achieve this be to
store only the to header as XTO, the cc header XCC, and the bcc
header as XBCC and use Xapian's multi-prefix support to map the to:
query prefix to XTO, XCC, and XBCC? That way you're not storing twice
as many copies of
might also want
notmuch-query_parser-add_prefix (to, XTO);
to maintain some form of backwards compatibility.
On Sun, Dec 12, 2010 at 5:43 AM, Joel Borggrén-Franck
joel.borggren.fra...@gmail.com wrote:
On Sun, Dec 12, 2010 at 7:41 AM, Austin Clements amdra...@gmail.com
wrote:
Short of full
It seems I somehow repeated the function prototypes for tags.c and
filenames.c twice at the bottom of notmuch-private.h (probably through some
rebase mishap). Obviously those should be deduplicated.
On Thu, Dec 9, 2010 at 3:59 PM, Austin Clements amdra...@mit.edu wrote:
diff --git a/lib
Note that the type:mail filter is implemented as a transform pass, so
it no longer has to be done everywhere queries are parsed.
Furthermore, this filter now depends on the prefixing logic in the
query parser instead of implementing this itself.
---
lib/database-private.h |3 +--
b/lib/qparser.cc
new file mode 100644
index 000..4804d06
--- /dev/null
+++ b/lib/qparser.cc
@@ -0,0 +1,941 @@
+/* qparser.cc - Notmuch query parser
+ *
+ * Copyright © 2010 Austin Clements
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms
Out of curiosity, has anyone considered using inotify to monitor maildirs
for new mail to hand to notmuch? For systems supporting inotify (or
equivalents), this would have the advantage of being compatible with any
delivery mechanism, be it a mail server, procmail, or emacs fcc'ing a
maildir.
On
This is version 2 of the custom query parser. It now supports date
searches with sane syntax, folder searches (without any additions or
changes to the database, unlike cworth's recent commit), and tag:*
and -tag:* queries for finding tagged and untagged messages. I used
these features to guide
100644
index 000..b86a445
--- /dev/null
+++ b/lib/qparser.cc
@@ -0,0 +1,920 @@
+/* qparser.cc - Notmuch query parser
+ *
+ * Copyright © 2010 Austin Clements
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License
This implements support in the lexer and generator for wildcard terms,
expanding them into synonym queries the way Xapian does. Since this
expansion is performed by the generator, it's easy to take advantage
of in query transforms.
With this, * works anywhere in the query, so we'll no longer
Note that the type:mail filter is implemented as a transform pass, so
it no longer has to be done everywhere queries are parsed.
Furthermore, this filter now depends on the prefixing logic in the
query parser instead of implementing this itself. Likewise, we don't
need to special-case the queries
This extends the syntactic-to-database prefix query transform to
optionally expand wildcards for boolean prefixes. Support of NOT
tag:* queries to find all untagged messages falls out as a convenient
side-effect.
---
TODO |2 --
lib/database.cc |4 ++--
The folder search implementation in the custom query parser is always rooted
(both because that happened to be much easier to do in that design, and
because I agree with you that rooted searches seem preferable most of the
time). What arguments do people have for or against rooted folder
+++ b/test/qparser-test.cc
@@ -0,0 +1,153 @@
+/* qparser-test - Display the lex, parse, and query tree for a query
+ *
+ * Copyright © 2011 Austin Clements
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License
---
This is intended to be applied after patch 2/8 in this series,
id:1295165458-9573-3-git-send-email-amdra...@mit.edu
test/qparser |5 ++
test/qparser.expected-output/near-and-adj | 83 +
test/qparser.expected-output/operators|
---
test/qparser-test.cc |6 +++---
test/qparser.expected-output/wildcards | 13 +
test/search| 12
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/test/qparser-test.cc b/test/qparser-test.cc
index
---
test/search | 67 +++
1 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/test/search b/test/search
index 7d1dedb..6425359 100755
--- a/test/search
+++ b/test/search
@@ -73,6 +73,73 @@ add_message '[subject]=this phrase
Quoth Carl Worth on Jan 26 at 9:59 pm:
On Wed, 26 Jan 2011 19:15:21 +1000, Carl Worth cwo...@cworth.org wrote:
But then I'm also wondering if perhaps we could do the processing undeferred
in all cases?
I haven't thought that through, but I'd be glad to hear your ideas.
This is still
Worth cwo...@cworth.org wrote:
On Wed, 26 Jan 2011 10:07:28 -0500, Austin Clements amdra...@mit.edu
wrote:
Quoth Carl Worth on Jan 26 at 9:59 pm:
I believe you're right that synchronization could always be done
eagerly. In fact, I believe this is true even with the addition of
conjunctive
, Jan 27, 2011 at 12:43 AM, Austin Clements amdra...@mit.edu wrote:
Sure. I've been wanting to take a crack at notmuch new's atomicity for a
while. Though you'll have to get through some of my outstanding patches. I
can only keep so many branches in my head. ]:--8
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
On Fri, Jan 28, 2011 at 10:36 AM, Mike Kelly pi...@pioto.org wrote:
On Fri, 28 Jan 2011 10:45:19 +0100, Thomas Schwinge tho...@schwinge.name
wrote:
It would definitely be nice to avoid the complexity inherent in having
a
daemon, but how do you imagine queue on a lock to work? We don't
)
flock -s 200;;
*)
flock -x 200;;
esac
$NOTMUCH_BIN $@ 200-
) 200$MAIL_DIR/.notmuch/lock
On Fri, Jan 28, 2011 at 11:57 AM, Austin Clements amdra...@mit.edu wrote:
On Fri, Jan 28, 2011 at 10:36 AM, Mike Kelly pi...@pioto.org wrote:
On Fri, 28 Jan 2011 10
)
}
delete notmuch-term_gen;
+delete notmuch-xapian_db;
talloc_free (notmuch);
}
On Fri, Jan 28, 2011 at 11:35 AM, Austin Clements amdra...@mit.edu wrote:
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
Jan 2011, Tom Prince wrote:
On 2011-01-23, Michal Sojka wrote:
Hi all,
the following patch series brings into notmuch date/time parser stolen
from GNU coreutils. It can be applied on top of custom query parser
patches from Austin Clements.
This is RFC and it not meant for merging
Remove the repeated sizeof (doc_ids-bitmap[0]) that bothered cworth
by instead defining macros to compute the word and bit offset of a
given bit in the doc ID set bitmap.
---
lib/query.cc | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/lib/query.cc
Don't require the caller of _notmuch_doc_id_set_init to pass in a
correct bound; instead compute it from the array. This simplifies the
caller and makes this interface easier to use correctly.
---
lib/query.cc | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git
I removed this line in a bout of overzealous deletions. The visible
consequence was that the database was being unlocked lazily, resulting
in a brief window after notmuch had exited but the database was still
locked.
---
I admit this patch series numbering is getting a little out of hand.
As
for the lexer, parser, and generator, but the
infrastructure for testing them needs cleanup before I send that out.
--
Austin Clements MIT/'06/PhD/CSAIL
amdra...@mit.edu http://web.mit.edu/amdragon
Somewhere in the dream we call
Quoth Carl Worth on Feb 02 at 2:48 pm:
Restricting my reply to one tiny bit of your mail:
You wrote:
non-recursive is the only thing that makes sense for Maildir++ folders
Either I'm not understanding Maildir++ folders, or I don't agree with
you.
I might have an email archive that
Nice catch.
Is there a reason you keep the remaining data in a string instead of
taking the more idiomatic elisp approach of leaving it in the process
buffer? In fact, the code would probably be simpler if you
immediately appended the string to the process buffer like a normal
process-filter and
On Feb 10, 2011 8:33 AM, Ben Gamari bgamari.f...@gmail.com wrote:
On Thu, 10 Feb 2011 12:20:55 +, Daniel Barlow d...@telent.net wrote:
My questions
1) (How) can I filter on the X-Spam-Bar header to chop out spam and
suspected spam?
I simply run new mail through bogofilter in my
I've rebased this against current master and fixed a few merge
conflicts. The rebased patches are on the eager-metadata-v3 branch of
http://awakening.csail.mit.edu/git/notmuch.git
On Thu, Dec 9, 2010 at 3:59 PM, Austin Clements amdra...@mit.edu wrote:
This is the second of the two
This patch series modifies notmuch new to perform all operations
atomically and to perform maildir flag synchronization eagerly. As a
result, notmuch new can be interrupted without risking database
consistency or losing track of messages, but still without losing
progress in the middle of a big
Previously, message removals were always performed, even after a
SIGINT. As a result, when a message was moved from one folder to
another, a SIGINT between processing the directory the message was
removed from and processing the directory it was added to would result
in notmuch removing that
Previously, if notmuch new were interrupted between updating the
directory mtime and handling removals from that directory, a
subsequent notmuch new would not handle those removals until something
else changed in that directory. This defers recording the updated
mtime until after removals are
---
lib/message.cc |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index 0590f76..06747fe 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -29,6 +29,7 @@ struct _notmuch_message {
notmuch_database_t *notmuch;
Make _notmuch_message_remove_filename return
NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID if the message has more filenames
and fix callers to handle this.
---
lib/message.cc | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index
The two new API functions, notmuch_database_find_message_by_filename
and notmuch_message_remove_filename give library users more control
over the filename removal process. notmuch_database_remove_message
has been reimplemented in terms of these new functions.
notmuch_message_remove_filename acts
These operations translate into non-flushed Xapian transactions,
allowing arbitrary groups of database operations to be performed
atomically.
---
lib/database.cc | 44
lib/notmuch.h | 30 ++
2 files changed, 74
Because flag synchronization is stateless, it can be performed at any
time as long as it's guaranteed to be performed after any change to a
message's filename list. Take advantage of this to synchronize tags
immediately after a filename is added or removed while the message is
still frozen. With
Looks good (faster than, but provably equivalent to the original code!
notmuch_directory_get_child_* are side-effect free,
db_files/db_subdirs aren't used between where they were set in the old
code and where they are set in the new code, and db_files/db_subdirs
are initialized to NULL when
Thanks!
Hope you feel better tomorrow.
Quoth Carl Worth on Mar 09 at 3:21 pm:
On Sun, 30 Jan 2011 23:22:31 -0500, Austin Clements amdra...@mit.edu wrote:
As usual, this is also available in my git repo
http://awakening.csail.mit.edu/git/notmuch.git
as the search-perf-3 branch
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
Much of the beauty of notmuch is how few assumptions it makes about
your mail system. It plays well with others. For example, one deep
insight of notmuch is that it *doesn't* require a custom mail store,
even though a more obvious design might; in fact, it doesn't even
require Maildir.
That
-0500, Austin Clements amdra...@mit.edu wrote:
I've rebased this against current master and fixed a few merge
conflicts. The rebased patches are on the eager-metadata-v3 branch of
http://awakening.csail.mit.edu/git/notmuch.git
Hi Austin,
This looks like a great set of optimizations
grind. Whoever said being a grad student was
hitting the snooze button on life was a liar.)
Responses inline.
On Fri, Mar 11, 2011 at 12:26 AM, Carl Worth cwo...@cworth.org wrote:
On Thu, 10 Mar 2011 21:47:30 -0500, Austin Clements amdra...@mit.edu wrote:
Yes, qparser-3 is ready for you, and has
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 Sun, Mar 27, 2011 at 1:26 AM, Jameson Rollins jroll...@finestructure.net
wrote:
On Sat, 26 Mar 2011 22:16:32 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
This enables the proper face customization UI for
notmuch-search-line-faces.
Hey, folks. amdragon was the one who
On Sun, Apr 17, 2011 at 2:23 PM, Jameson Graef Rollins
jroll...@finestructure.net wrote:
By giving notmuch new a path to a message in the store:
notmuch new /path/to/message
By feeding notmuch new a message on stdin, and then having it write
the message to a specified location:
notmuch
This tests notmuch new's ability to recover from arbitrary stopping
failures. It interrupts notmuch new after every database commit and,
on every resulting database snapshot, re-runs notmuch new to
completion and checks that the final database state is invariant.
---
This addresses a timing bug
On Wed, May 4, 2011 at 4:26 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
+output=$(notmuch search from:'search-by-from@' | notmuch_search_sanitize)
I don't think this does what you think it does. Xapian only
understands double quotes around phrases, not single quotes.
Furthermore, a
Quoth Felipe Contreras on May 04 at 11:54 pm:
On Wed, May 4, 2011 at 11:46 PM, Austin Clements amdra...@mit.edu wrote:
On Wed, May 4, 2011 at 4:26 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
+output=$(notmuch search from:'search-by-from@' | notmuch_search_sanitize)
I don't
This is awesome. What was your machine configuration?
As another data point, with a probably very different configuration (8
year old P4, new SSD), my test query was 1.9X faster uncached and 1.6X
faster cached. It also produced 60% fewer disk reads. I saw the same
1% increase in database size.
On Wed, May 4, 2011 at 9:48 PM, Austin Clements amdra...@mit.edu wrote:
As another data point, with a probably very different configuration (8
year old P4, new SSD), my test query was 1.9X faster uncached and 1.6X
faster cached. It also produced 60% fewer disk reads. I saw the same
1
Cool. This seems very reasonable.
Just some style nits: The three places where you have
sanitize_string(, there should be a space between the function name
and the paren. Relatedly, for(;*loop;loop++){ should be spaced out
like for (; *loop; loop++) {. (Curiously, there seems to be
Your commit message is inconsistent with your change; is your intent to
return None or the empty string? Also, could you modify your commit message
to say what those are?
On May 9, 2011 3:06 AM, Anton Khirnov an...@khirnov.net wrote:
___
notmuch mailing
This looks good to me (and is certainly more correct), but seems
rather roundabout. Is there a reason this code doesn't simply (princ
(buffer-string))?
On Tue, May 10, 2011 at 1:40 AM, Dmitry Kurochkin
dmitry.kuroch...@gmail.com wrote:
The patch replaces all (message (buffer-string)) calls in
Previously, the test assumed the generated message would be assigned a
specific thread ID; now it doesn't. Also, spelling fix.
---
This applies to the current 0.6 RC head (9f8ef78e).
test/search-output |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git
For these types of tests, the test name is previously recorded in a
variable, not passed to the test function, so pass this variable to
test_skip.
---
test/test-lib.sh |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index
This makes test_expect_* return non-zero if the test fails, so the
caller can make decisions based on this, such as setting test
prerequisites.
---
test/test-lib.sh |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 9b56406..955350a
-0400, Austin Clements amdra...@mit.edu wrote:
On Thu, May 12, 2011 at 8:22 AM, Pieter Praet pie...@praet.org wrote:
The atomicity tests were failing here because I didn't have GDB
installed, so I've added it as a prereq.
Sorry, I've had a patch to address that sitting around, but hadn't
sent
I wonder if a better approach would be to use
notmuch_message_get_header everywhere, rather than introducing
_notmuch_message_get_header_value, and have it simply recognize
headers that can be retrieved directly from the database. Then
library callers could take advantage of this optimization and
On Tue, May 24, 2011 at 6:16 PM, Dmitry Kurochkin
dmitry.kuroch...@gmail.com wrote:
When a user clicks the button, the cursor is somewhere inside the old
label. If we save the point as a marker, after step 3 it would end up
at the position where the old label was. If the new label is inserted
Out of curiosity, what use cases do you envision for this? So far
I've only heard two, both of which seem like great ideas, but neither
of which require such a heavy-handed solution: displaying unread
counts for tags rather than total counts, and hiding unused tags.
I would argue that we
On Wed, May 25, 2011 at 6:04 AM, Daniel Schoepe
daniel.scho...@googlemail.com wrote:
On Wed, 25 May 2011 00:10:43 -0400, Austin Clements amdra...@mit.edu wrote:
Out of curiosity, what use cases do you envision for this? So far
I've only heard two, both of which seem like great ideas
On Wed, May 25, 2011 at 1:56 PM, Daniel Schoepe
daniel.scho...@googlemail.com wrote:
I accidentally used `filter' in the previous patch which isn't defined
by default during runtime, updated version in the attachment.
Cool. My inner parser is happy.
A few comments on the code:
+(defcustom
On Wed, May 25, 2011 at 5:21 PM, Daniel Schoepe
daniel.scho...@googlemail.com wrote:
On Wed, 25 May 2011 15:11:16 -0400, Austin Clements amdra...@mit.edu wrote:
So, perhaps something like
(defcustom notmuch-hello-tag-list-counts nil
Method for generating counts displayed in the all tags
On May 25, 2011 7:21 PM, Daniel Schoepe daniel.scho...@googlemail.com
wrote:
On Wed, 25 May 2011 18:42:30 -0400, Austin Clements amdra...@mit.edu
wrote:
'Doh. That's what I get for not reading the surrounding code. I
misunderstood what your patch was going for and assumed it was what
*I
On May 26, 2011 1:20 PM, Carl Worth cwo...@cworth.org wrote:
The question: How do you solve this in the emacs code?
do you store all tids of a query?
The emacs code does not use the notmuch library interface like your
python bindings do. Instead, it uses the notmuch command-line tool, (and
On Thu, May 26, 2011 at 6:22 PM, Patrick Totzke
patricktot...@googlemail.com wrote:
Excerpts from Austin Clements's message of Thu May 26 22:43:02 +0100 2011:
Though, Patrick, that solution doesn't address your problem. On the
other hand, it's not clear to me what concurrent access
On Fri, May 27, 2011 at 2:04 PM, Patrick Totzke
patricktot...@googlemail.com wrote:
Excerpts from Austin Clements's message of Fri May 27 03:41:44 +0100 2011:
Have you tried simply calling list() on your thread
iterator to see how expensive it is? My bet is that it's quite cheap,
On Sat, May 28, 2011 at 5:58 PM, Jameson Graef Rollins
jroll...@finestructure.net wrote:
Austin: speaking of which, would you mind rebasing that patch series
against notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937 and
sending that to the list again? That might help push Carl to
Rebased to current master (cb8418) as atomic-new-v4 (aka
for-review/atomic-new-v4).
On Wed, May 4, 2011 at 4:30 PM, Austin Clements amdra...@mit.edu wrote:
jrollins found a timing bug in the atomicity test. A fix, plus beefed
up test comments are on a new atomic-new-v3 (and
for-review/atomic
Quoth Patrick Totzke on May 28 at 9:58 am:
Excerpts from Austin Clements's message of Fri May 27 20:29:24 +0100 2011:
On Fri, May 27, 2011 at 2:04 PM, Patrick Totzke
patricktot...@googlemail.com wrote:
Excerpts from Austin Clements's message of Fri May 27 03:41:44 +0100 2011:
Have
This looks good to me, and should be merged sooner rather than later
because it touches a lot of lines.
If atomic-new-v4 doesn't happen to get merged before this, then
id:1305206080-17461-1-git-send-email-amdra...@mit.edu and
id:1305206110-17511-1-git-send-email-amdra...@mit.edu should get
On Thu, Jun 2, 2011 at 10:20 AM, Sebastian Spaeth sebast...@sspaeth.de wrote:
On Thu, 2 Jun 2011 19:43:29 +1000, Brian May wrote:
On 2 June 2011 17:05, Sebastian Spaeth sebast...@sspaeth.de wrote:
What would be the best way to solve this (besides fixing the C api to
allow to reset the
Nifty!
On Sat, Jun 4, 2011 at 8:19 AM, Daniel Schoepe
daniel.scho...@googlemail.com wrote:
+ (minibuffer-completion-table (completion-table-dynamic
+ `(lambda (s) (notmuch-query-completions
+ (quote
Quoth Daniel Schoepe on Jun 04 at 9:55 pm:
On Sat, 4 Jun 2011 11:32:15 -0400, Austin Clements amdra...@mit.edu wrote:
Dynamic scoping is obnoxious, but I think programmed completion is
steeped in the assumption that you'll use it. This code would be much
simpler if notmuch-query
Also, slightly reformat dir-locals.el so that the settings align and
to make it friendlier for future additions.
---
.dir-locals.el | 18 ++
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/.dir-locals.el b/.dir-locals.el
index cbdb1f9..eff29fc 100644
---
Quoth Dmitry Kurochkin on Jun 07 at 9:27 am:
Hi Austin.
On Tue, 7 Jun 2011 01:20:25 -0400, Austin Clements amdra...@mit.edu wrote:
Also, slightly reformat dir-locals.el so that the settings align and
to make it friendlier for future additions.
---
.dir-locals.el | 18
On Tue, Jun 7, 2011 at 2:38 AM, Dima Kogan notm...@dima.secretsauce.net wrote:
On Tue, 7 Jun 2011 01:20:25 -0400
Austin Clements amdra...@mit.edu wrote:
Also, slightly reformat dir-locals.el so that the settings align and
to make it friendlier for future additions.
Should we also add
Also, slightly reformat dir-locals.el so that the settings align and
to make it friendlier for future additions.
---
.dir-locals.el | 24
1 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/.dir-locals.el b/.dir-locals.el
index cbdb1f9..aea630b 100644
---
This looks really interesting.
I haven't examined the code very closely, but I have some high level comments.
It seems that the code is simultaneously trying to do something very
general, but also hard-coding a lot of behaviors, and I think the
code's complexity suffers for it. What would this
Quoth Carl Worth on Jun 08 at 3:05 pm:
On Sat, 28 May 2011 22:51:10 -0400, Austin Clements amdra...@mit.edu wrote:
Rebased to current master (cb8418) as atomic-new-v4 (aka
for-review/atomic-new-v4).
Hi Austin,
Thanks so much for sending this series (and 4 times, even!).
I *really
Previously, if notmuch new were interrupted between updating the
directory mtime and handling removals from that directory, a
subsequent notmuch new would not handle those removals until something
else changed in that directory. This defers recording the updated
mtime until after removals are
notmuch_database_t now keeps a nesting count and we only start a
transaction or commit for the outermost atomic section.
Introduces a new error, NOTMUCH_STATUS_UNBALANCED_ATOMIC.
---
lib/database-private.h |1 +
lib/database.cc| 22 ++
lib/notmuch.h |
Make _notmuch_message_remove_filename return
NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID if the message has more filenames
and fix callers to handle this.
---
lib/message.cc |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index
1 - 100 of 3381 matches
Mail list logo
