at the moment anywhere in the code.
Signed-off-by: Sebastian Spaeth
---
lib/notmuch.h |3 ++-
lib/query.cc |2 ++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index a7e66dd..bae48a6 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -346,7
On 2010-04-15, Olly Betts wrote:
> > I would be happy to have it called --sort=relevance too, the unsorted
> > points out potential performance improvements a bit better, IMHO
> > (although they seem to be really small with a warm cache).
>
> When using the results of a search to add/remove
On 2010-04-15, Olly Betts wrote:
I would be happy to have it called --sort=relevance too, the unsorted
points out potential performance improvements a bit better, IMHO
(although they seem to be really small with a warm cache).
When using the results of a search to add/remove tags,
In some cases, we might not be interested in any special sort order, so
this introduces a --sort=unsorted command line option together with its
documentation.
Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de
---
notmuch-search.c |2 ++
notmuch.1| 10 ++
notmuch.c
It's not neccessary to sort the results before we apply tags. Xapian
contributor Olly Betts says that savings might be bigger with a cold
file cache and (as unsorted implies really sorted by document id) a better
cache locality when applying tags to messages.
Signed-off-by: Sebastian Spaeth
We previously output notmuch version 0.1 as response to notmuch --version.
Shorten this to notmuch 0.1 as we know that we will receive a version
number when we explicitely ask for it.
Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de
---
notmuch.c |2 +-
1 files changed, 1 insertions
On 2010-04-16, Dirk Hohndel wrote:
+Thirdparty apps
+---
+(not sure this is the best spot to collect requests like this)
+
+notmuchsync
+
+Add feature to move files in the maildir hierarchy
+
+ notmuchsync --move searchstring targetfolder
+ Where searchstring is any
On 2010-04-14, Michal Sojka wrote:
> On Tue, 13 Apr 2010, Servilio Afre Puentes wrote:
> > The current hardcoded behaviour will not take you to the next unread
> > thread when the sort order is set to newer-first from the default of
> > older-first.
>
> Is this really what we want? If I sort
On 2010-04-14, David Edmondson wrote:
> This really should be done with `define-mail-user-agent' and associated
> paraphernalia.
Which might be correct but beyond what I can provide :).
So, either we take this and get a followup patch, or someone improves
it, or we drop it.
Sebastian
On 2010-04-14, Jason White wrote:
> > Also add a --sort=unsorted command line option to notmuch search to test
> > this.
>
> Does this provide relevance-ranked search results? I think relevance ranking
> is the Xapian default if a sort order isn't specified.
Yes, by default it is using
On 2010-04-13, Carl Worth wrote:
> > OK, final post from me on this issue.
> No, wait! I want more from you. :-)
Sigh, they always want more :-)
> Would you care to put together a solution that does this from within
> notmuch*.el ? I really want things usable by default without people
> having
This adds a function (and a hook) to have notmuch insert a User-Agent header
into composed mails (even if invoked from not-notmuch ways, such as with
ctrl-x m. This is invariably added for now without the possibility to
turn it off, a task left as a homework for others.
Signed-off-by: Sebastian
in default sort in 0.982 seconds
and unsorted in 0.978 seconds with very little variance (with a warm cache).
Xapian contributor Olly Betts says that the speed gains for a cold cache are
likely to be much higher though.
Signed-off-by: Sebastian Spaeth
---
lib/notmuch.h|3 ++-
lib/query.cc
in default sort in 0.982 seconds
and unsorted in 0.978 seconds with very little variance (with a warm cache).
Xapian contributor Olly Betts says that the speed gains for a cold cache are
likely to be much higher though.
Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de
---
lib/notmuch.h
This adds a function (and a hook) to have notmuch insert a User-Agent header
into composed mails (even if invoked from not-notmuch ways, such as with
ctrl-x m. This is invariably added for now without the possibility to
turn it off, a task left as a homework for others.
Signed-off-by: Sebastian
On 2010-04-14, Jason White wrote:
Also add a --sort=unsorted command line option to notmuch search to test
this.
Does this provide relevance-ranked search results? I think relevance ranking
is the Xapian default if a sort order isn't specified.
Yes, by default it is using
On 2010-04-14, David Edmondson wrote:
This really should be done with `define-mail-user-agent' and associated
paraphernalia.
Which might be correct but beyond what I can provide :).
So, either we take this and get a followup patch, or someone improves
it, or we drop it.
Sebastian
On 2010-04-12, Jameson Rollins wrote:
> On Mon, 12 Apr 2010 15:33:35 +0200, "Sebastian Spaeth" > Wow, this is really
> interesting, Sebastian. For those of us not in the
> know, can you explain what libeatmydata is and how it's used?
Hehe, I just got the pointer to i
fsync is really killing xapian (and notmuch). What suffers, are the
boolean prefixes (tag, id, and thread). Using libeatmydata (which
disables fsync) shows a 10x speedup for tagging. The speedup is only
factor 2 for e.g. from: searches. This is ext4 on recent stock
Ubuntu. Given that search by tag
On Mon, 12 Apr 2010 09:14:27 +0100, David Edmondson wrote:
> How about this approach:
ooh! me likey!
Thanks, very nice to get an overview over all my tags.
OK, final post from me on this issue. This is what I am using in my
.emacs now. It does not clutter up the message compose window with a
User-Agent header as it is hidden by message mode. It is also not shown
by default in the notmuch-show modes but viewing the full headers
confirms that it is
On 2010-04-10, Anthony Towns wrote:
> Hi *,
>
> The attached patch makes "notmuch new --new-tags=unread,new" set the
> "unread" and "new" tags on any new mail it finds rather than "unread"
> and "inbox". Or whatever other tags you happen to specify.
Thanks for the patch. I can't comment on the
After some research, this is what I found/propose:
With some simple elisp am I using this User-Agent header now:
User-Agent: notmuch version 0.1 (Emacs 23.1.1/i486-pc-linux-gnu)
This needs to be done:
1) Add "User-Agent" to the variable "message-required-headers" (it is
(optional .
OK, final post from me on this issue. This is what I am using in my
.emacs now. It does not clutter up the message compose window with a
User-Agent header as it is hidden by message mode. It is also not shown
by default in the notmuch-show modes but viewing the full headers
confirms that it is
On Mon, 12 Apr 2010 09:14:27 +0100, David Edmondson d...@dme.org wrote:
How about this approach:
ooh! me likey!
Thanks, very nice to get an overview over all my tags.
___
notmuch mailing list
notmuch@notmuchmail.org
fsync is really killing xapian (and notmuch). What suffers, are the
boolean prefixes (tag, id, and thread). Using libeatmydata (which
disables fsync) shows a 10x speedup for tagging. The speedup is only
factor 2 for e.g. from: searches. This is ext4 on recent stock
Ubuntu. Given that search by tag
On 2010-04-12, Jameson Rollins wrote:
On Mon, 12 Apr 2010 15:33:35 +0200, Sebastian Spaeth Wow, this is really
interesting, Sebastian. For those of us not in the
know, can you explain what libeatmydata is and how it's used?
Hehe, I just got the pointer to it on IRC myself:
http
After some research, this is what I found/propose:
With some simple elisp am I using this User-Agent header now:
User-Agent: notmuch version 0.1 (Emacs 23.1.1/i486-pc-linux-gnu)
This needs to be done:
1) Add User-Agent to the variable message-required-headers (it is
(optional . User-Agent)
On 2010-04-09, Carl Worth wrote:
>
> Here's the current list:
Having such a list is great. So now we need to get you a key-binding
that says, "take query xy results and stuff them into the wiki" (or some
pastebin like service with a fixed URL). Looking forward to 0.2.
Sebastian
(THanks to the
On 2010-04-10, Carl n?tmuch ? Worth wrote:
> Are you all trying to show a problem here? All of the above comes
> through fine. Perhaps it's only with non-ASCII in the From line being
> replied to? Let's test that here...
I think there are 2 issues being discussed here. One is the encoding in
the
On 2010-04-09, Jesse Rosenthal wrote:
> sporadic access. However, one question: it looks like it was V2 of the
> patch that you pushed -- was it? Unfortunately, there was a subtle bug
> that kept on popping up (when you call notmuch-show interactively, which
> rarely happens). Later in this same
On 2010-04-10, Carl n∅tmuch 䚳 Worth wrote:
Are you all trying to show a problem here? All of the above comes
through fine. Perhaps it's only with non-ASCII in the From line being
replied to? Let's test that here...
I think there are 2 issues being discussed here. One is the encoding in
the
On 2010-04-09, Carl Worth wrote:
Here's the current list:
Having such a list is great. So now we need to get you a key-binding
that says, take query xy results and stuff them into the wiki (or some
pastebin like service with a fixed URL). Looking forward to 0.2.
Sebastian
(THanks to the
On 2010-04-10, Carl Worth wrote:
So I propose something like:
User-Agent: Notmuch/0.2 (http://notmuchmail.org) Emacs/23.1.1 (gnu/linux)
That looks good to me. So I assume the correct strategy here would be
to:
1) have notmuch reply insert a header:
User-Agent: Notmuch/0.2
On 2010-04-08, Mike Kelly wrote:
> If no parameters are given to notmuch-count, or just '' or '*' are
> given, return the total number of messages in the database.
I know that cworth was concerned about this syntax on IRC as that would
mean that "notmuch show" would have to spew out all your
On 2010-04-09, Michal Sojka wrote:
> "Decode headers in reply"
> (id:1267602656-24940-1-git-send-email-sojkam1 at fel.cvut.cz) is another
> patch, which is quite essential to me. Am I the only one here, who needs
> to reply to messages with non-ASCII characters?
Nope, and it looks currently very
On 2010-04-08, Michal Sojka wrote:
> I think that the patch you sent was not the latest version. The latest
> is in id:1265122868-12133-1-git-send-email-sojkam1 at fel.cvut.cz, but it
> is not rebased to the current master.
Not sure what I am doing wrong, but with this patch even after a
On 2010-04-08, Michal Sojka wrote:
I think that the patch you sent was not the latest version. The latest
is in id:1265122868-12133-1-git-send-email-sojk...@fel.cvut.cz, but it
is not rebased to the current master.
Not sure what I am doing wrong, but with this patch even after a
notmuch is (mostly) not responsible for sending email. However, people
using the emacs frontend use notmuch to create the reply.
Am I the only one who is sometimes curious as to what mail agents others
use? Would it be useful to insert a header to notmuch reply analog to:
User-Agent: Mutt/1.5.13
On 2010-04-07, Dirk Hohndel wrote:
>
> The previous code made too many assumptions about the (sadly not
> standardized) format of the Received headers. This version should
> be more robust to deal with different variations.
This code might be useful for some, but I know it is not being useful
First of all, thanks for the great work Carl. I have to admit I was
getting nervous about the backlog of patches, but your recent committing
binge (you did say your work patterns are bursty :-)) made me very happy.
That having said, I am glad to meet your expectation: "I expect people
to remind
First of all, thanks for the great work Carl. I have to admit I was
getting nervous about the backlog of patches, but your recent committing
binge (you did say your work patterns are bursty :-)) made me very happy.
That having said, I am glad to meet your expectation: I expect people
to remind
notmuch is (mostly) not responsible for sending email. However, people
using the emacs frontend use notmuch to create the reply.
Am I the only one who is sometimes curious as to what mail agents others
use? Would it be useful to insert a header to notmuch reply analog to:
User-Agent: Mutt/1.5.13
On 2010-04-07, micah anderson wrote:
> > > The only other patch that I find absolutely crucial, that you do not
> > > include, is the 'Preserve folder information when indexing' patch which,
> > > although not perfect, does significantly change my life.
This patch in included in my branch now.
---
notmuch-reply.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index e69e7a4..f26ca39 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -402,7 +402,7 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t
*config,
---
notmuch-reply.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index e69e7a4..f26ca39 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -402,7 +402,7 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t
*config,
On 2010-04-07, micah anderson wrote:
The only other patch that I find absolutely crucial, that you do not
include, is the 'Preserve folder information when indexing' patch which,
although not perfect, does significantly change my life.
This patch in included in my branch now. There is a
On 2010-04-06, Michal Sojka wrote:
> I often have several versions of notmuch compiled and it would be very
> helpful to be able to distinguish between them. Git has a very nice
> feature to make intermediate numbering automatic and unambiguous so
> let's use it here.
But, there are people
On Mon, 5 Apr 2010 14:50:04 +0100, Enrico Zini wrote:
> Now I use "lbdb", which gets very slow as time goes. You idea creates a
> most definitely superior system.
You can actually use both :): Do check out the patch on the mailing list
to combine the notmuch address lookup with bbdb via EUDC. It
ed-off-by: Jesse Rosenthal
Signed-off-by: Sebastian Spaeth
---
emacs/notmuch-show.el | 11 ---
emacs/notmuch.el | 14 --
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index cc1f905..ed95afb 100644
--- a
On Sat, 06 Mar 2010 09:20:21 -0500, Jesse Rosenthal
wrote:
> Change the buffer name to a uniquified subject of the thread (i.e. the
> subject of the first message in the thread) instead of the thread-id. This
> is more meaningful to the user, and will make it easier to scroll through
> numerous
From: David Edmondson <d...@dme.org>
Patch from mail id:1266226909-19360-1-git-send-email-dme at dme.org with a fix
in id:873a12hl3f.fsf at aw.hh.sledj.net
Signed-off-by: Sebastian Spaeth
---
emacs/notmuch-show.el | 18 ++
1 files changed, 10 insertions(+), 8 del
ed-off-by: Sebastian Spaeth
---
emacs/notmuch-show.el | 36 +---
1 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index cc1f905..f172f6b 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -111,10 +
On Wed, 17 Feb 2010 10:51:51 +, David Edmondson wrote:
> In many conversations the last few lines of a citation are more
> interesting than the first few lines, hence allow those to be shown if
> desired.
>
> Modify the face used for the citation button to distinguish it from
> the
From: Aneesh Kumar K.V <aneesh.ku...@gmail.com>
Add key binding to do a reply-to sender. This is mapped to 'R'
Signed-off-by: Aneesh Kumar K.V
Signed-off-by: Sebastian Spaeth
---
emacs/notmuch-show.el | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff
From: Aneesh Kumar K.V
This patch add --recipient=all|sender option
Signed-off-by: Aneesh Kumar K.V
---
notmuch-client.h |2 +
notmuch-reply.c | 55 -
2 files changed, 43 insertions(+), 14 deletions(-)
diff
I just rebased these two patches as the files have been moved around. I
use those patches and they work fine for me, by the way. Patches will
arrive in a second as reply to this message.
Sebastian
On Wed, 17 Feb 2010 10:51:51 +, David Edmondson d...@dme.org wrote:
In many conversations the last few lines of a citation are more
interesting than the first few lines, hence allow those to be shown if
desired.
Modify the face used for the citation button to distinguish it from
the
-by: Sebastian Spaeth sebast...@sspaeth.de
---
emacs/notmuch-show.el | 36 +---
1 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index cc1f905..f172f6b 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
From: David Edmondson d...@dme.org
Patch from mail id:1266226909-19360-1-git-send-email-...@dme.org with a fix in
id:873a12hl3f@aw.hh.sledj.net
Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de
---
emacs/notmuch-show.el | 18 ++
1 files changed, 10 insertions(+), 8
On Sat, 06 Mar 2010 09:20:21 -0500, Jesse Rosenthal jrosent...@jhu.edu wrote:
Change the buffer name to a uniquified subject of the thread (i.e. the
subject of the first message in the thread) instead of the thread-id. This
is more meaningful to the user, and will make it easier to scroll
-by: Jesse Rosenthal jrosent...@jhu.edu
Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de
---
emacs/notmuch-show.el | 11 ---
emacs/notmuch.el | 14 --
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index
On Mon, 5 Apr 2010 14:50:04 +0100, Enrico Zini enr...@enricozini.org wrote:
Now I use lbdb, which gets very slow as time goes. You idea creates a
most definitely superior system.
You can actually use both :): Do check out the patch on the mailing list
to combine the notmuch address lookup with
I really want to replace my address book with dynamic notmuch searches
and while python gives me those in 0.3 seconds or so, I wanted better.
So I bound notmuch.so to vala (at least what I needed) and played with
the code a bit. The resulting 100 lines of vala code are here:
On 2010-04-03, C?dric Cabessa wrote:
> libnotmuch.so is in my personal folder, I'd like to use LD_LIBRARY_PATH for
> that.
> The problem is that find_library does not read this variable, but hopefully
> CDLL does.
>
> I suggest to not use find_library. If the library do not exist, we just have
>
I really want to replace my address book with dynamic notmuch searches
and while python gives me those in 0.3 seconds or so, I wanted better.
So I bound notmuch.so to vala (at least what I needed) and played with
the code a bit. The resulting 100 lines of vala code are here:
On 2010-04-03, Cédric Cabessa wrote:
libnotmuch.so is in my personal folder, I'd like to use LD_LIBRARY_PATH for
that.
The problem is that find_library does not read this variable, but hopefully
CDLL does.
I suggest to not use find_library. If the library do not exist, we just have
to
On Thu, 01 Apr 2010 00:54:16 -0700, Carl Worth wrote:
> Finally, I'm a tiny bit annoyed that now after a fresh checkout of
> notmuch and "make" that one can't easily run ./notmuch without either
> installing the library (or fiddling with LD_LIBRARY_PATH). I've got some
> ideas on how to simplify
On Thu, 01 Apr 2010 00:54:16 -0700, Carl Worth cwo...@cworth.org wrote:
Finally, I'm a tiny bit annoyed that now after a fresh checkout of
notmuch and make that one can't easily run ./notmuch without either
installing the library (or fiddling with LD_LIBRARY_PATH). I've got some
ideas on how
On Mon, 29 Mar 2010 10:17:01 +0100, David Edmondson wrote:
> > I fear this is not correct. I cloned notmuch from Carl's git repository,
> > and whenever I press 'RET' while the point is over the subject line, the
> > result is the same as pressing 'h': the subject information gets toggled.
>
>
On Sun, 28 Mar 2010 07:46:40 +0200, Michal Sojka wrote:
> I don't think this can be solved only in Makefile. From my look at dme's
> repo, he adds a new subcomand 'part', which is used by the UI. So if you
> want to use the new UI and your other features, you need to merge the
> things together.
On Fri, 12 Mar 2010 17:13:26 -0500, Ben Gamari
wrote:
> /* success */
> case NOTMUCH_STATUS_SUCCESS:
> state->added_messages++;
> - tag_inbox_and_unread (message);
> + for (tag=state->new_tags; *tag != NULL; tag++)
> + notmuch_message_add_tag
> Oh, sorry. I thought it is so trivial, that I didn't even compile it for
> master. The right version is here:
Thanks, that worked fine now. I pushed it to my branch.
Sebastian
Oh, sorry. I thought it is so trivial, that I didn't even compile it for
master. The right version is here:
Thanks, that worked fine now. I pushed it to my branch.
Sebastian
___
notmuch mailing list
notmuch@notmuchmail.org
On Fri, 12 Mar 2010 17:13:26 -0500, Ben Gamari bgamari.f...@gmail.com wrote:
/* success */
case NOTMUCH_STATUS_SUCCESS:
state-added_messages++;
- tag_inbox_and_unread (message);
+ for (tag=state-new_tags; *tag != NULL; tag++)
+
On Mon, 29 Mar 2010 10:17:01 +0100, David Edmondson d...@dme.org wrote:
I fear this is not correct. I cloned notmuch from Carl's git repository,
and whenever I press 'RET' while the point is over the subject line, the
result is the same as pressing 'h': the subject information gets toggled.
On Sun, 28 Mar 2010 00:37:00 +0100, "Sebastian Spaeth" wrote:
> On Fri, 26 Mar 2010 22:18:13 +0100, Michal Sojka
> wrote:
> > When Ctrl-C is pressed in a wrong time during notmuch new, it can lead
> > to removal of messages from the database even if the files w
On Mon, 22 Mar 2010 14:47:39 +, David Edmondson wrote:
> I'm pushed the first stage of a JSON based emacs UI to the repository at
> http://github.com/dme/notmuch (it's in the "master" branch).
Despite the switch to daylight savings time stealing me an hour of this
night, I managed to test
On Sun, 28 Mar 2010 03:22:31 +0200, Sebastian Spaeth
wrote:
> This has changed!!!:
> --dryrun has become --dry-run for consistency with git
Ohh, one last thing, it no longer does an implicit "notmuch new"
(because that is not implemented in cnotmuch (yet?)) so call that before
Hi all, I just pushed an experimental branch to notmuchsync that uses
notmuch.so and my cnotmuch bindings. It needs some cleanup and
documentation, but it worked on my box.If you feel adventorous, get it from
git clone git at github.com:spaetz/notmuchsync.git
The new stuff is in branch cnotmuch.
On Fri, 26 Mar 2010 22:18:13 +0100, Michal Sojka wrote:
> When Ctrl-C is pressed in a wrong time during notmuch new, it can lead
> to removal of messages from the database even if the files were not
> removed.
Thanks, applied in my feature-all branch.
Sebastian
On Fri, 26 Mar 2010 18:39:17 +, Michael Forney
wrote:
> ---
> lib/notmuch.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Thanks, applied in my feature-all branch
Sebastian
On Thu, 25 Mar 2010 22:50:52 -0400, micah anderson wrote:
> On Mon, 01 Mar 2010 15:57:00 +0100, "Sebastian Spaeth" SSpaeth.de> wrote:
>
> > From git repository git://github.com/spaetz/notmuch-all-feature.git I
> > would like to advocate the following b
On Fri, 26 Mar 2010 18:39:17 +, Michael Forney mich...@obberon.com wrote:
---
lib/notmuch.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Thanks, applied in my feature-all branch
Sebastian
___
notmuch mailing list
On Fri, 26 Mar 2010 22:18:13 +0100, Michal Sojka sojk...@fel.cvut.cz wrote:
When Ctrl-C is pressed in a wrong time during notmuch new, it can lead
to removal of messages from the database even if the files were not
removed.
Thanks, applied in my feature-all branch.
Sebastian
Hi all, I just pushed an experimental branch to notmuchsync that uses
notmuch.so and my cnotmuch bindings. It needs some cleanup and
documentation, but it worked on my box.If you feel adventorous, get it from
git clone g...@github.com:spaetz/notmuchsync.git
The new stuff is in branch cnotmuch.
FYI: The python bindings for notmuch.so are now API complete and I
released them as version 0.2.1.
See:
http://pypi.python.org/pypi/cnotmuch for an overview and downloads.
http://bitbucket.org/spaetz/cnotmuch/ the source code repo/history
http://packages.python.org/cnotmuch/ the API documentation
FYI: The python bindings for notmuch.so are now API complete and I
released them as version 0.2.1.
See:
http://pypi.python.org/pypi/cnotmuch for an overview and downloads.
http://bitbucket.org/spaetz/cnotmuch/ the source code repo/history
http://packages.python.org/cnotmuch/ the API documentation
g the integration. First comment:
When I search for "Seb", the first 2 hits, I get are:
Sebastian Spaeth
Sebastian Spaeth
I think the version I sent you, lower-cased all email addresses. Is it
intentional to have these as 2 separate email addresses?
Sebastian
> if I remember, there has been at least three different patches for this,
> so you are the fourth :-) You're right that it helps a lot with initial
> import. To promote my work a little bit, I use bidirectional
> synchronization between maildir flags and notmuch tags, which I sent in
>
if I remember, there has been at least three different patches for this,
so you are the fourth :-) You're right that it helps a lot with initial
import. To promote my work a little bit, I use bidirectional
synchronization between maildir flags and notmuch tags, which I sent in
On Mon, 22 Mar 2010 11:14:22 +0100, Ruben Pollan
wrote:
> Nice feature. I think it should be implemented in the library. There is
> already
> a function notmuch_database_get_all_tags, will be nice to have a function
> notmuch_database_get_all_addresses.
Actually, i don't think it's necessary
Hey all, given that there is at least one user of cnotmuch out there
now, I just put it up on the python package repository:
http://pypi.python.org/pypi/cnotmuch
This means you can do "easy_install cnotmuch" on your linux box and it
will get installed into:
On Mon, 22 Mar 2010 00:13:57 +0100, Michal Sojka wrote:
> On Sun, 21 Mar 2010, Sebastian Spaeth wrote:
> > That reminds me that there is still no installation tool for cnotmuch at
> > all. I'll have to have a look into that.
>
> Hi, I have also a silly question :) Why did
On Mon, 22 Mar 2010 00:13:57 +0100, Michal Sojka sojk...@fel.cvut.cz wrote:
On Sun, 21 Mar 2010, Sebastian Spaeth wrote:
That reminds me that there is still no installation tool for cnotmuch at
all. I'll have to have a look into that.
Hi, I have also a silly question :) Why did you call
On Mon, 22 Mar 2010 11:14:22 +0100, Ruben Pollan mes...@sindominio.net wrote:
Nice feature. I think it should be implemented in the library. There is
already
a function notmuch_database_get_all_tags, will be nice to have a function
notmuch_database_get_all_addresses.
Actually, i don't think
On Sat, 20 Mar 2010 22:35:42 -0400, Jesse Rosenthal
wrote:
> I've written a python script (with some help and suggestions
> from spaetz) which can perform the address-book functionality, and a
> backend for emacs's EUDC address-lookup functionality to access the
> script.
Thanks for sharing, I
On Sat, 20 Mar 2010 11:23:20 +0100, Ruben Pollan
wrote:
>
> Adds support to reverse iteration on messages, threads and tags. To revew and
> think if makes sense to include them on notmuch or wait until they have a real
> use.
/me raises arm. Real use case here! Personally, I don't need the
On Sat, 20 Mar 2010 11:23:20 +0100, Ruben Pollan mes...@sindominio.net wrote:
Adds support to reverse iteration on messages, threads and tags. To revew and
think if makes sense to include them on notmuch or wait until they have a real
use.
/me raises arm. Real use case here! Personally, I
On Sat, 20 Mar 2010 22:35:42 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
I've written a python script (with some help and suggestions
from spaetz) which can perform the address-book functionality, and a
backend for emacs's EUDC address-lookup functionality to access the
script.
Thanks
401 - 500 of 654 matches
Mail list logo