Hi,
>
> Here is my workaround. If this approach seems sensible I can prepare a
> patch to `org-notmuch-follow-link` in ol-notmuch.el.
Your approach probably works most of the time, but I don't like the idea
of having to perform 2 queries when one should be enough.
I think a better approach w
- "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' s
- "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.
>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 not
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
- ra...@free.fr a écrit :
> Carl: The patch in the mail has problems; apparently I have to
> manually add scissorlines to the mail for
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
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
> > 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:
>
- "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.ga15...@lapse.rw.madduck.net
I don't understand the probl
>On Thu, 11 Feb 2010 15:20:54 +0100 (CET), ra...@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 for
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 toggl
Works with the following patch (replace a DT_UKNOWN with DT_UNKNOWN, else it
fails to compile)
Matthieu
- Mail Original -
De: "Carl Worth"
À: ra...@free.fr, "Ali Polatel"
Cc: notmuch@notmuchmail.org
Envoyé: Samedi 23 Janvier 2010 07h06:12 GMT +01:00 Amsterdam / Berlin / Berne /
Rome
Hi Sebastian,
I posted a similar patch a while ago, that also did not show deleted messages
by default. Don't know if Carl wants to
integrate this though
Matthieu
- Mail Original -
De: "Sebastian Spaeth"
À: "notmuch"
Envoyé: Mercredi 20 Janvier 2010 10h32:10 GMT +00:00 GMT - Grande-B
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 b740ee2..4
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 th
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, ra...@free.fr wrote:
> > OK, I had a problem using this #!#)($! webmail client. Here's th
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, ra...@free.fr wrote:
> > Here is a first attempt to add "smart completion" to notmuch-search.
>
> Hi Matthieu,
>
> This all sounds quite interesting!
>
> I
Hum, sure...
Matthieu
Quoting Carl Worth :
> On Fri, 18 Dec 2009 16:00:49 +0100, ra...@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. ;-)
>
> -Carl
>
Hi!
Here is a first attempt to add "smart completion" to notmuch-search.
What it does is that:
- It tries to detects when you hit tab to complete a search term
prefix (like to, from, subject...) , and if so completes your
prefix;
- If you try to complete a search term usign a specific
19 matches
Mail list logo
