The archive operation should only archive open messages

- "Carl Worth" a ?crit : > Once we fix that, I think we can go back to having tag operations > only > affect matched messages in the search view, and I agree that this > will > be extremely convenient. > What about using prefixes to each command, the way Gnus does it*? For instance, 'd'

please eat my data!

- "Jameson Rollins" a ?crit : > On Mon, 12 Apr 2010 15:33:35 +0200, "Sebastian Spaeth" > wrote: > > 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.

[notmuch] What's so great about notmuch?

>What's your favorite thing about notmuch? The simple, functional emacs interface (rmail is too simple and Gnus too complex). Especially, I like the idea that many commands create new bufferes, that get deleted with "q", so that access to buffers is done like in a stack. >What about

[notmuch] [PATCH] Support for deletion (patch included)

Here they are; as I don't know how to include them in the body, I put the patches as attachments. I hope this will be convienient enough for you. Matthieu - racin at free.fr a ?crit : > Carl: The patch in the mail has problems; apparently I have to > manually add scissorlines to the mail

[notmuch] [PATCH] Support for deletion (patch included)

Carl: The patch in the mail has problems; apparently I have to manually add scissorlines to the mail for it to be processed by git-am. I thought this was automatically added. (I hate the git UI -- nothing is consistent, concepts have different names, the definition of scissor lines is as precise

[notmuch] [PATCH] Support for deletion (patch included)

Hi Carl, > Could you also write a commit message describing what the patch does? > The easiest way for me to apply that would be if you would create a git > commit, then run "git format-patch origin/master" and mail the resulting > files, (the "git send-email" command can be used here, or you can

[notmuch] JSON output as default [was: Re: [PATCH] Add an "--output=(json|text|)" command-line option...]

> > I definitely want to be able to pipe single-field lists coming from > > notmuch to grep, xargs, shell for loops, etc. without having to > decode > > JSON. > > While I would love to see JSON (even by default), I agree. If I just > want to code up a notmuch-based address book with sth like: >

[notmuch] Git ancestry and sync problems (was: Mail in git)

- "martin f krafft" a ?crit : > Except I fear that as soon as we allow manipulation of the local > store, we'll potentially run into this problem: > > http://notmuchmail.org/pipermail/notmuch/2010/001114.html > id:20100112045152.GA15275 at lapse.rw.madduck.net I don't understand the

[notmuch] notmuch.el: Prefix arg inverts the sort order of notmuch-search.

>On Thu, 11 Feb 2010 15:20:54 +0100 (CET), racin at free.fr wrote: > >> Using a prefix arg to invert search order would conflict with my patch >> http://notmuchmail.org/pipermail/notmuch/2009/000914.html in which the >> prefix arg is used to show deleted messages. I don't known which >> behaviour

[notmuch] notmuch.el: Prefix arg inverts the sort order of notmuch-search.

Using a prefix arg to invert search order would conflict with my patch http://notmuchmail.org/pipermail/notmuch/2009/000914.html in which the prefix arg is used to show deleted messages. I don't known which behaviour for prefix patch would be best. Though we can also add "toggle keys" that

[notmuch] Bug with commit 2e96464f9705be4ec772280cad71a6c9d5831e6f

Works with the following patch (replace a DT_UKNOWN with DT_UNKNOWN, else it fails to compile) Matthieu - Mail Original - De: "Carl Worth" ?: racin at free.fr, "Ali Polatel" Cc: notmuch at notmuchmail.org Envoy?: Samedi 23 Janvier 2010 07h06:12 GMT +01:00 Amsterdam / Berlin / Berne /

[notmuch] Bug with commit 2e96464f9705be4ec772280cad71a6c9d5831e6f

I still confirm the bug. The problem is due to relying on non-standardized fields of directory entries (i.e. d_type), which don't behave the same on reiserfs than on ext2 (I use reiserfs). The following ugly patch "solves" my problem. diff --git a/notmuch-new.c b/notmuch-new.c index

[notmuch] Bug with commit 2e96464f9705be4ec772280cad71a6c9d5831e6f

Hello, I just updated notmuch and now notmuch new cannot update my mail anymore... It tells me that there are 700 files found, but tells that there's no new mail. I did a git bisect, which tells me the first bad commit is commit 2e96464f9705be4ec772280cad71a6c9d5831e6f. I did not try to use

[notmuch] First attempt to add smart completion in notmuch-search

Well, then it's useful for [subject, from, to], right? :) In the future, other prefix terms, like tags, could also be completed this way. Matthieu Quoting Kan-Ru Chen : > On Thu, 24 Dec 2009 11:07:16 +0100, racin at free.fr wrote: > > OK, I had a problem using this #!#)($! webmail client.

[notmuch] First attempt to add smart completion in notmuch-search

OK, I had a problem using this #!#)($! webmail client. Here's the patch. Matthieu Quoting Carl Worth : > On Fri, 18 Dec 2009 16:00:49 +0100, racin at free.fr wrote: > > Here is a first attempt to add "smart completion" to notmuch-search. > > Hi Matthieu, > > This all sounds quite interesting! >

[notmuch] First attempt to add smart completion in notmuch-search

Hum, sure... Matthieu Quoting Carl Worth : > On Fri, 18 Dec 2009 16:00:49 +0100, racin at free.fr wrote: > > Here is a first attempt to add "smart completion" to notmuch-search. > > Hi Matthieu, > > This all sounds quite interesting! > > I look forward to actually seeing the patch. ;-) > >