[PATCH 1/3] query.cc: allow to return query results unsorted

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

[PATCH] allow to not sort the search results

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

Re: [PATCH] allow to not sort the search results

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,

[PATCH 2/3] notmuch-search: Introduce --sort=unsorted

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

[PATCH 3/3] notmuch-tag: don't sort messages before applying tag changes

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

[PATCH] notmuch.c: Shorten version string

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

notmuchsync --move (was: add a number of new feature ideas to TODO file)

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

[PATCH] emacs: when archiving move the cursor depending on the sort order.

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

[PATCH 13/13] notmuch.el: Add a function to insert a notmuch user-agent header

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

[PATCH] allow to not sort the search results

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

[PATCH] RFC: User-Agent header

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

[PATCH 13/13] notmuch.el: Add a function to insert a notmuch user-agent header

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

[PATCH] allow to not sort the search results

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

[PATCH] allow to not sort the search results

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

[PATCH 13/13] notmuch.el: Add a function to insert a notmuch user-agent header

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

Re: [PATCH] allow to not sort the search results

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

Re: [PATCH 13/13] notmuch.el: Add a function to insert a notmuch user-agent header

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

please eat my data!

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

please eat my data!

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

sup-like label listings (elisp)

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.

[PATCH] RFC: User-Agent header

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

[PATCH] notmuch new --new-tags=tags...

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

RFC: User-Agent header

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 .

Re: [PATCH] RFC: User-Agent header

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

Re: sup-like label listings (elisp)

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

please eat my data!

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

Re: please eat my data!

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

Re: RFC: User-Agent header

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)

Initial attempt at a "merge window" for notmuch

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

Plans for the 0.2 release (this week)

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

[notmuch] [PATCH v2] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id

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

Re: Plans for the 0.2 release (this week)

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

Re: Initial attempt at a merge window for notmuch

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

Re: RFC: User-Agent header

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

[PATCH] Have notmuch count default to showing the total.

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

Plans for the 0.2 release (this week)

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

[notmuch] [Sebastian Spaeth] Pull requests

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

Re: [notmuch] [Sebastian Spaeth] Pull requests

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

RFC: User-Agent header

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

[PATCH] Fix code extracting the MTA from Received: headers

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

Plans for the 0.2 release (this week)

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

Re: Plans for the 0.2 release (this week)

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

RFC: User-Agent header

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

[notmuch] [Sebastian Spaeth] Pull requests

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.

[PATCH] * notmuch-reply.c: 542e32876 introduced a superfluous { in an if statement

--- 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,

[PATCH] * notmuch-reply.c: 542e32876 introduced a superfluous { in an if statement

--- 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,

Re: [notmuch] [Sebastian Spaeth] Pull requests

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

[PATCH] Derive version numbers from git

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

[notmuch] vala, this is notmuch. notmuch, this is vala

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

[PATCH] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id (supersedes V1--3)

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

[notmuch] [PATCH V4] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id (supersedes V1--3)

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

[PATCH 2/2] notmuch.el: Colour cited regions and signatures with message-cited-text-face

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

[PATCH 1/2] notmuch.el: Allow citation suffixes to be shown as well as prefixes.

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 +

[notmuch] [PATCH] notmuch.el: Allow citation suffixes to be shown as well as prefixes.

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

[PATCH 2/2] notmuch.el: Add support for reply-to sender

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

[PATCH 1/2] notmuch-reply: Add support for replying only to sender

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

[notmuch] [PATCH -V2 1/2] notmuch-reply: Add support for replying only to sender

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

Re: [notmuch] [PATCH] notmuch.el: Allow citation suffixes to be shown as well as prefixes.

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

[PATCH 1/2] notmuch.el: Allow citation suffixes to be shown as well as prefixes.

-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

[PATCH 2/2] notmuch.el: Colour cited regions and signatures with message-cited-text-face

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

Re: [notmuch] [PATCH V4] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id (supersedes V1--3)

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

[PATCH] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id (supersedes V1--3)

-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

Re: [notmuch] vala, this is notmuch. notmuch, this is vala

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

[notmuch] vala, this is notmuch. notmuch, this is vala

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:

[notmuch] cnotmuch 0.1.1 release

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 >

[notmuch] vala, this is notmuch. notmuch, this is vala

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:

Re: [notmuch] cnotmuch 0.1.1 release

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

[notmuch] Notmuch shared library

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

Re: [notmuch] Notmuch shared library

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

[notmuch] JSON based emacs UI

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. > >

[notmuch] JSON based emacs UI

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.

[notmuch] [PATCH] notmuch-config: make new message tags configurable

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

[notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

> 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

Re: [notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

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

Re: [notmuch] [PATCH] notmuch-config: make new message tags configurable

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++) +

Re: [notmuch] JSON based emacs UI

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.

[notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

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

[notmuch] JSON based emacs UI

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

[notmuch] notmuchsync, now with new formula ;-)

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

[notmuch] notmuchsync, now with new formula ;-)

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.

[notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

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

[notmuch] [PATCH] Fix typo in notmuch.h documentation regarding database open modes

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

[notmuch] [Sebastian Spaeth] Pull requests

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

Re: [notmuch] [PATCH] Fix typo in notmuch.h documentation regarding database open modes

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

Re: [notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

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

[notmuch] notmuchsync, now with new formula ;-)

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.

[notmuch] cnotmuch 0.2.1 release (API complete)

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

[notmuch] cnotmuch 0.2.1 release (API complete)

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

[notmuch] Using notmuch as an address book for tab-completion

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

[notmuch] [PATCH] notmuch-new: Parse some maildir flags for labels

> 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 >

Re: [notmuch] [PATCH] notmuch-new: Parse some maildir flags for labels

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

[notmuch] Using notmuch as an address book for tab-completion

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

[notmuch] cnotmuch 0.1.1 release

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:

[notmuch] Using notmuch as an address book for tab-completion

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

Re: [notmuch] Using notmuch as an address book for tab-completion

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

Re: [notmuch] Using notmuch as an address book for tab-completion

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

[notmuch] Using notmuch as an address book for tab-completion

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

[notmuch] reverse iterators

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

Re: [notmuch] reverse iterators

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

Re: [notmuch] Using notmuch as an address book for tab-completion

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

<    1   2   3   4   5   6   7   >