[notmuch] reading with multiple MUAs from MailDir

[Dirk Hohndel]

While playing with notmuch I am still using evolution to read the email
in the same MailDir that is being indexed / processed by notmuch. With
the result that lots of emails can not be found in notmuch if they have
been marked as read in evolution between processing in notmuch and
trying to access them from the user interface.

This makes notmuch /really/ hard to test for me at this point.

Is there a workaround?

/D


-- 
Dirk Hohndel
Intel Open Source Technology Center

[notmuch] emacs mode performance issue

[Dirk Hohndel]

I'm in the search results window in Emacs, on an LKML thread with 140+
messages. I hit return to view this thread - Emacs consumes 100% CPU
but even after waiting 3 minutes it doesn't display the result (this is
on a fast system Lenovo x200s). 

C-g stops the process and gets me dumped into a clearly partially
processed buffer.

Is there a good way to collect more profiling information to figure out
why this is so slow?

/D


-- 
Dirk Hohndel
Intel Open Source Technology Center

[notmuch] Patch for xapian defect #250

[Carl Worth]

On Thu, 10 Dec 2009 15:00:42 +0800, Kan-Ru Chen  wrote:
> The termlist is already sorted, so this is the patch trying to minimize
> the modification of database as suggested in the comment and Carl's
> TODO file.

Fantastic, Kan-Ru!

> My poor profiling shows not much, but some improvement.

Now you're just understating for sake of the pun. A 5-6x performance
improvement looks great. And I see that as well in my testing:

Before:

$ time notmuch tag +foo tag:sent
real 3m18.067s
$ time notmuch tag -foo tag:sent
real 3m12.940s

After:

$ time notmuch tag +foo tag:sent
real 0m31.497s
$ time notmuch tag -foo tag:sent
real 0m28.722s

I didn't flush the OS caches between runs, but a subsequent run of the
"before" code still performed similarly slow:

$ time notmuch tag +foo tag:sent
real 3m7.172s

And if I *had* used cold caches for every run the benefit of the patch
would have looked even better.

Anyway, we should get this upstream to the Xapian folks straight
away. I expect they'll want to see a patch to the chert backend as well
as the flint backend, (but fortunately the relevant code looks very
similar if not identical).

Thanks again,

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091210/69b46e52/attachment.pgp>

[notmuch] Threading

[Marten Veldthuis]

On Thu, 10 Dec 2009 09:39:48 -0800, Carl Worth  wrote:
> I think the right answer here is to fix the input that notmuch is
> getting. Just ensure that each message has a proper In-Reply-To header
> and all should be fine.

On a related note, what about communicating with people who press reply
on an existing message, change the subject and start a new mail
thread. Most mail clients will still insert the In-Reply-To header,
which in this case is just wrong.

Ofcourse, it's their fault, but one can't educate the entire world. Is
there anything like mutt has, to break a thread at the current message?

-- 
- Marten

[notmuch] [PATCH 2/2] Save all attachments to a directory

[Carl Worth]

On Sat,  5 Dec 2009 14:54:00 -0800, Keith Amidon  wrote:
> Prompt for a directory and write all attachments of the current
> message to that directory, prompting for a filename for each with a
> default value of the filename specified in the attachment.

I really like the idea of this function. I'd just like to see a few,
little improvements.

> The behavior of this function differs in two ways from the existing
> notmuch-show-save-attachments function:

First, I'm not sure whether we need two different variations of what's
effectively the same operation here ("save all attachments").

What I would like is one command to save a single attachment, and then
one command to save all attachments. So if we assume that the current
'w' keybinding is really for "write one attachment" (with a lame
implementation currently), and 'W' is for "write all attachments", then
I think I'd be OK with that.

As for the changes we need here, the prompting for the directory needs
a string telling the user what's being prompted for. Something like
"Save all attachments to: ", which should just be another argument to
the interactive call, right?

Second, the command needs to provide a little bit of feedback as to what
was saved. I ended up running this command a couple of times before I
realized it was never going to save the inline patch with no filename
that I was looking at[*].

So it at least needs to message something like "N files written to DIR"
or so.

Should be fairly trivial improvements to the current patch I think.

-Carl

[*] So there's something else I think we need here. I was seeing a patch
in a message, but wanted to get it into a file before piping it off to
something, (so '|' didn't work). The patch wasn't an attachment so 'w'
didn't work as described above. I tried using 'V' to view the raw
message, but then found that the MIME part I wanted was actually encoded
as quoted-printable, so just saving the raw message wasn't useful
either.

So do we need a command to write the current "cooked" message to a file?
I suppose I could have just used:

| cat > /some/filename

but that feels a little bit like cat abuse.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091210/5f61d87f/attachment.pgp>

[notmuch] [PATCH 1/2] Expand scope of items considered when saving attachments

[Carl Worth]

On Sat,  5 Dec 2009 14:53:59 -0800, Keith Amidon  wrote:
> Previously only mime parts that indicated specified a "disposition" of
> "attachment" were saved.  However there are time when it is important
> to be able to save inline content as well.  After this commit any mime
> part that specifies a filename will be considered when saving
> attachments.

Yes, this seems obviously like what we want---thanks!

I've pushed this out now.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091210/d316db3f/attachment.pgp>

[notmuch] Patch for xapian defect #250

[Kan-Ru Chen]

.get_wdf();
-   new_doclen += wdf;
-
-   string tname = *term;
-   if (tname.size() > MAX_SAFE_TERM_LENGTH)
-   throw Xapian::InvalidArgumentError("Term too long (> 
"STRINGIZE(MAX_SAFE_TERM_LENGTH)"): " + tname);
-   map<string, pair<termcount_diff, termcount_diff> >::iterator i;
-   i = freq_deltas.find(tname);
-   if (i == freq_deltas.end()) {
-   freq_deltas.insert(make_pair(tname, make_pair(1, 
termcount_diff(wdf;
-   } else {
-   ++i->second.first;
-   i->second.second += wdf;
-   }
+new_doclen += wdf;
+
+if (cmp > 0) {
+  if (tname.size() > MAX_SAFE_TERM_LENGTH)
+throw Xapian::InvalidArgumentError("Term too long (> 
"STRINGIZE(MAX_SAFE_TERM_LENGTH)"): " + tname);
+  map<string, pair<termcount_diff, termcount_diff> >::iterator 
i;
+  i = freq_deltas.find(tname);
+  if (i == freq_deltas.end()) {
+freq_deltas.insert(make_pair(tname, make_pair(1, 
termcount_diff(wdf;
+  } else {
+++i->second.first;
+i->second.second += wdf;
+  }
+
+  // Add did to tname's postlist
+  map<string, map<docid, pair<char, termcount> > >::iterator j;
+  j = mod_plists.find(tname);
+  if (j == mod_plists.end()) {
+map<docid, pair<char, termcount> > m;
+j = mod_plists.insert(make_pair(tname, m)).first;
+  }
+  map<docid, pair<char, termcount> >::iterator k;
+  k = j->second.find(did);
+  if (k != j->second.end()) {
+Assert(k->second.first == 'D');
+k->second.first = 'M';
+k->second.second = wdf;
+  } else {
+j->second.insert(make_pair(did, make_pair('A', wdf)));
+  }
+}
+
+PositionIterator it = term.positionlist_begin();
+PositionIterator it_end = term.positionlist_end();
+if (it != it_end) {
+  position_table.set_positionlist(
+  did, tname, it, it_end);
+} else {
+  position_table.delete_positionlist(did, tname);
+}
+  }
+  if (termlist.at_end())
+++term;
+  else if (term == term_end)
+termlist.next();
+  else {
+if (cmp >= 0)
+  ++term;
+if (cmp <= 0)
+  termlist.next();
+  }
+}

-   // Add did to tname's postlist
-   map<string, map<docid, pair<char, termcount> > >::iterator j;
-   j = mod_plists.find(tname);
-   if (j == mod_plists.end()) {
-   map<docid, pair<char, termcount> > m;
-   j = mod_plists.insert(make_pair(tname, m)).first;
-   }
-   map<docid, pair<char, termcount> >::iterator k;
-   k = j->second.find(did);
-   if (k != j->second.end()) {
-   Assert(k->second.first == 'D');
-   k->second.first = 'M';
-   k->second.second = wdf;
-   } else {
-   j->second.insert(make_pair(did, make_pair('A', wdf)));
-   }
-
-   PositionIterator it = term.positionlist_begin();
-   PositionIterator it_end = term.positionlist_end();
-   if (it != it_end) {
-   position_table.set_positionlist(
-   did, tname, it, it_end);
-   } else {
-   position_table.delete_positionlist(did, tname);
-   }
-   }
LOGLINE(DB, "Calculated doclen for replacement document " << did << 
" as " << new_doclen);

// Set the termlist


-- 
Kan-Ru Chen | http://kanru.info

Q: Why are my replies five sentences or less?
A: http://five.sentenc.es/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091210/3a0f0e53/attachment.pgp>

[notmuch] Threading

[Carl Worth]

On Thu, 10 Dec 2009 20:08:18 +0100, Marten Veldthuis  
wrote:
> On a related note, what about communicating with people who press reply
> on an existing message, change the subject and start a new mail
> thread. Most mail clients will still insert the In-Reply-To header,
> which in this case is just wrong.

Just this morning I sent a mail to the notmuch list, which was a reply,
(and legitimately so), but also potentially of interest to everyone on
the list, (since it was regarding a bug fix unrelated to the original
topic of the thread I was replying to).

So I was stuck on whether I should break the thread or not, (at the
sending end). I guess I could have just sent a quick "this is pushed"
reply, and independently composed a separate message telling people
about the fix.

I ended up keeping the threading intact in that case, (which I think is
right). But maybe what we really want here is for notmuch to just
provide a bit more indication about subject changes (say, at the search
view). For example, I could imagine each subject change getting its own
line in the search view, (perhaps initially hidden with a button to
expand them). Obviously this would have to ignore trivial changes like
adding a "Re:" or a "[LISTNAME]" prefix.

> Ofcourse, it's their fault, but one can't educate the entire world. Is
> there anything like mutt has, to break a thread at the current message?

Not now. It would be a pretty trivial operation at the library level,
(just telling the library to generate a new random thread ID for a
particular message---and then to also recompute thread IDs for
descendant messages).

But I still have a hard time justifying user operations to manipulate
threading. The whole point of threading is to make it faster to process
and read messages. But manual operations like joining and splitting
threads seem like the user just doing more work, and that *after* having
read the messages. So that seems mostly backwards to me.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091210/e1c66001/attachment.pgp>

[notmuch] [Orgmode] Notmuch: An emacs interface for fast global search and tagging of email

[Jed Brown]

On Wed, 09 Dec 2009 12:00:21 -0800, Carl Worth  wrote:
> 1. Rewriting the code to not use apply-partially

1b. Use apply-partially

(defun apply-partially (fun  args)
  "Return a function that is a partial application of FUN to ARGS.
ARGS is a list of the first N arguments to pass to FUN.
The result is a new function which does the same as FUN, except that
the first N arguments are fixed at the values with which this function
was called."
  (lexical-let ((fun fun) (args1 args))
(lambda ( args2) (apply fun (append args1 args2)


Jed

[notmuch] [PATCH] notmuch.el: patch notmuch-show to call notmuch show without query-context (i.e. without tag:inbox) if the first query returns nothing.

[da...@tethera.net]

From: David Bremner 

This fixes the annoying bug of archiving a thread, and then going back
to open it and getting an error.  It needs the notmuch-show API
changing patch of 1259979997-31544-3-git-send-email-david at tethera.net.
---

I'm not really expecting Carl to push this patch, because I think he
has a better solution in mind, but in the mean time maybe someone
finds it useful. It is saving my sanity already, since in wanderlust
 'a' = reply :).

 notmuch.el |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index cf472f7..0cd4386 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -997,7 +997,9 @@ matching this search term are shown if non-nil. "
   (save-excursion
(let* ((basic-args (list notmuch-command nil t nil "show" 
"--entire-thread" thread-id))
(args (if query-context (append basic-args (list "and (" 
query-context ")")) basic-args)))
- (apply 'call-process args))
+ (apply 'call-process args)
+ (when (and (eq (buffer-size) 0) query-context)
+   (apply 'call-process basic-args)))
(notmuch-show-markup-messages)
)
   (run-hooks 'notmuch-show-hook)
-- 
1.6.5.3

[notmuch] Fix viewing of thread after accidentally archiving.

[Carl Worth]

On Thu, 10 Dec 2009 11:14:35 -0400, david at tethera.net wrote:
> From: David Bremner 
> 
> This fixes the annoying bug of archiving a thread, and then going back
> to open it and getting an error.  It needs the notmuch-show API
> changing patch of 1259979997-31544-3-git-send-email-david at tethera.net.
> ---
> 
> I'm not really expecting Carl to push this patch, because I think he
> has a better solution in mind, but in the mean time maybe someone
> finds it useful. It is saving my sanity already, since in wanderlust
>  'a' = reply :).

On the contrary, David. I pushed this immediately, so thanks!

I'll still do the other solution, (other interfaces will want it), but
in the meantime, it's *really* nice to have this bug fixed.

I also fixed '+' and '-' to work in this same situation, (so you can
actually put an inbox tag *back* if you accidentally remove it). I
haven't yet fixed '*' for this case, so an accidental '* -inbox' won't
be recoverable with '* +inbox' if the current search is tag:inbox.

I've added a TODO item to fix this, (and the proposed fix there will
incidentally fix '*' to actually provide feedback on the added/removed
tags too, which will also help).

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091210/886aadc0/attachment.pgp>

[notmuch] [Orgmode] Notmuch: An emacs interface for fast global search and tagging of email

[Mark Anderson]

Excerpts from Jed Brown's message of Thu Dec 10 05:26:25 -0700 2009:
> On Wed, 09 Dec 2009 12:00:21 -0800, Carl Worth  wrote:
> > 1. Rewriting the code to not use apply-partially
> 
> 1b. Use apply-partially
> 
> (defun apply-partially (fun  args)
>   "Return a function that is a partial application of FUN to ARGS.
> ARGS is a list of the first N arguments to pass to FUN.
> The result is a new function which does the same as FUN, except that
> the first N arguments are fixed at the values with which this function
> was called."
>   (lexical-let ((fun fun) (args1 args))
> (lambda ( args2) (apply fun (append args1 args2)

Thanks, that is nice to have. Maybe after about 13 years of Emacs use I'll try 
to learn more lisp than Google-copy-paste.

Unfortunately for my specific case, that still didn't let the '?' key work.

if: Symbol's function definition is void: mouse-event-p

I seem to have lots of issues in emacs 22.2, but my Elisp is weak enough that I 
don't know how this ought to be handled.

There is the possibility of requiring 23.1 for notmuch.el, that may be easier, 
then I'll just stop trying with 22.2

Thanks again,
-Mark

[notmuch] Threading

[Carl Worth]

On Wed, 9 Dec 2009 16:21:34 -0700, Mark Anderson  
wrote:
> I was wondering if there's a way in notmuch to group un-associated
> threads into a single thread.

There's certainly nothing like that in notmuch currently.

Sup had user-level functionality in the interface for stitching messages
into a single thread, and I definitely think that that doesn't make any
sense.

> I have a bug tracking system that doesn't give me emails that thread 
> naturally in notmuch.

I've seen similar things. Bugzilla emails at least all group into a
single thread in notmuch, but don't get nested correctly at all, and
that's really annoying.

> I wouldn't mind writing a filter that could help identify a thread id
> which should apply to a message, and suggest that to notmuch.

I think the right answer here is to fix the input that notmuch is
getting. Just ensure that each message has a proper In-Reply-To header
and all should be fine. If you can't fix the bug-tracking system to emit
proper email, can you apply your filter and rewrite the message as part
of delivery (before notmuch sees it)?

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091210/21fad1d8/attachment.pgp>

Re: [notmuch] [Orgmode] Notmuch: An emacs interface for fast global search and tagging of email

[Jed Brown]

On Wed, 09 Dec 2009 12:00:21 -0800, Carl Worth cwo...@cworth.org wrote:
 1. Rewriting the code to not use apply-partially

1b. Use apply-partially

(defun apply-partially (fun rest args)
  Return a function that is a partial application of FUN to ARGS.
ARGS is a list of the first N arguments to pass to FUN.
The result is a new function which does the same as FUN, except that
the first N arguments are fixed at the values with which this function
was called.
  (lexical-let ((fun fun) (args1 args))
(lambda (rest args2) (apply fun (append args1 args2)


Jed
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [Orgmode] Notmuch: An emacs interface for fast global search and tagging of email

[Mark Anderson]

Excerpts from Jed Brown's message of Thu Dec 10 05:26:25 -0700 2009:
 On Wed, 09 Dec 2009 12:00:21 -0800, Carl Worth cwo...@cworth.org wrote:
  1. Rewriting the code to not use apply-partially
 
 1b. Use apply-partially
 
 (defun apply-partially (fun rest args)
   Return a function that is a partial application of FUN to ARGS.
 ARGS is a list of the first N arguments to pass to FUN.
 The result is a new function which does the same as FUN, except that
 the first N arguments are fixed at the values with which this function
 was called.
   (lexical-let ((fun fun) (args1 args))
 (lambda (rest args2) (apply fun (append args1 args2)

Thanks, that is nice to have. Maybe after about 13 years of Emacs use I'll try 
to learn more lisp than Google-copy-paste.

Unfortunately for my specific case, that still didn't let the '?' key work.

if: Symbol's function definition is void: mouse-event-p

I seem to have lots of issues in emacs 22.2, but my Elisp is weak enough that I 
don't know how this ought to be handled.

There is the possibility of requiring 23.1 for notmuch.el, that may be easier, 
then I'll just stop trying with 22.2

Thanks again,
-Mark

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Threading

[Carl Worth]

On Wed, 9 Dec 2009 16:21:34 -0700, Mark Anderson markr.ander...@amd.com wrote:
 I was wondering if there's a way in notmuch to group un-associated
 threads into a single thread.

There's certainly nothing like that in notmuch currently.

Sup had user-level functionality in the interface for stitching messages
into a single thread, and I definitely think that that doesn't make any
sense.

 I have a bug tracking system that doesn't give me emails that thread 
 naturally in notmuch.

I've seen similar things. Bugzilla emails at least all group into a
single thread in notmuch, but don't get nested correctly at all, and
that's really annoying.

 I wouldn't mind writing a filter that could help identify a thread id
 which should apply to a message, and suggest that to notmuch.

I think the right answer here is to fix the input that notmuch is
getting. Just ensure that each message has a proper In-Reply-To header
and all should be fine. If you can't fix the bug-tracking system to emit
proper email, can you apply your filter and rewrite the message as part
of delivery (before notmuch sees it)?

-Carl


pgp2IZfAgQCpG.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Fix viewing of thread after accidentally archiving.

[Carl Worth]

On Thu, 10 Dec 2009 11:14:35 -0400, da...@tethera.net wrote:
 From: David Bremner brem...@unb.ca
 
 This fixes the annoying bug of archiving a thread, and then going back
 to open it and getting an error.  It needs the notmuch-show API
 changing patch of 1259979997-31544-3-git-send-email-da...@tethera.net.
 ---
 
 I'm not really expecting Carl to push this patch, because I think he
 has a better solution in mind, but in the mean time maybe someone
 finds it useful. It is saving my sanity already, since in wanderlust
  'a' = reply :).

On the contrary, David. I pushed this immediately, so thanks!

I'll still do the other solution, (other interfaces will want it), but
in the meantime, it's *really* nice to have this bug fixed.

I also fixed '+' and '-' to work in this same situation, (so you can
actually put an inbox tag *back* if you accidentally remove it). I
haven't yet fixed '*' for this case, so an accidental '* -inbox' won't
be recoverable with '* +inbox' if the current search is tag:inbox.

I've added a TODO item to fix this, (and the proposed fix there will
incidentally fix '*' to actually provide feedback on the added/removed
tags too, which will also help).

-Carl


pgp1DUQJqipZe.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Threading

[Marten Veldthuis]

On Thu, 10 Dec 2009 09:39:48 -0800, Carl Worth cwo...@cworth.org wrote:
 I think the right answer here is to fix the input that notmuch is
 getting. Just ensure that each message has a proper In-Reply-To header
 and all should be fine.

On a related note, what about communicating with people who press reply
on an existing message, change the subject and start a new mail
thread. Most mail clients will still insert the In-Reply-To header,
which in this case is just wrong.

Ofcourse, it's their fault, but one can't educate the entire world. Is
there anything like mutt has, to break a thread at the current message?

-- 
- Marten
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH 1/2] Expand scope of items considered when saving attachments

[Carl Worth]

On Sat,  5 Dec 2009 14:53:59 -0800, Keith Amidon ke...@nicira.com wrote:
 Previously only mime parts that indicated specified a disposition of
 attachment were saved.  However there are time when it is important
 to be able to save inline content as well.  After this commit any mime
 part that specifies a filename will be considered when saving
 attachments.

Yes, this seems obviously like what we want---thanks!

I've pushed this out now.

-Carl


pgpyL7q9Lx30S.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH 2/2] Save all attachments to a directory

[Carl Worth]

On Sat,  5 Dec 2009 14:54:00 -0800, Keith Amidon ke...@nicira.com wrote:
 Prompt for a directory and write all attachments of the current
 message to that directory, prompting for a filename for each with a
 default value of the filename specified in the attachment.

I really like the idea of this function. I'd just like to see a few,
little improvements.

 The behavior of this function differs in two ways from the existing
 notmuch-show-save-attachments function:

First, I'm not sure whether we need two different variations of what's
effectively the same operation here (save all attachments).

What I would like is one command to save a single attachment, and then
one command to save all attachments. So if we assume that the current
'w' keybinding is really for write one attachment (with a lame
implementation currently), and 'W' is for write all attachments, then
I think I'd be OK with that.

As for the changes we need here, the prompting for the directory needs
a string telling the user what's being prompted for. Something like
Save all attachments to: , which should just be another argument to
the interactive call, right?

Second, the command needs to provide a little bit of feedback as to what
was saved. I ended up running this command a couple of times before I
realized it was never going to save the inline patch with no filename
that I was looking at[*].

So it at least needs to message something like N files written to DIR
or so.

Should be fairly trivial improvements to the current patch I think.

-Carl

[*] So there's something else I think we need here. I was seeing a patch
in a message, but wanted to get it into a file before piping it off to
something, (so '|' didn't work). The patch wasn't an attachment so 'w'
didn't work as described above. I tried using 'V' to view the raw
message, but then found that the MIME part I wanted was actually encoded
as quoted-printable, so just saving the raw message wasn't useful
either.

So do we need a command to write the current cooked message to a file?
I suppose I could have just used:

| cat  /some/filename

but that feels a little bit like cat abuse.


pgpxVGiEYtZ5t.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Patch for xapian defect #250

[Carl Worth]

On Thu, 10 Dec 2009 15:00:42 +0800, Kan-Ru Chen ka...@kanru.info wrote:
 The termlist is already sorted, so this is the patch trying to minimize
 the modification of database as suggested in the comment and Carl's
 TODO file.

Fantastic, Kan-Ru!

 My poor profiling shows not much, but some improvement.

Now you're just understating for sake of the pun. A 5-6x performance
improvement looks great. And I see that as well in my testing:

Before:

$ time notmuch tag +foo tag:sent
real 3m18.067s
$ time notmuch tag -foo tag:sent
real 3m12.940s

After:

$ time notmuch tag +foo tag:sent
real 0m31.497s
$ time notmuch tag -foo tag:sent
real 0m28.722s

I didn't flush the OS caches between runs, but a subsequent run of the
before code still performed similarly slow:

$ time notmuch tag +foo tag:sent
real 3m7.172s

And if I *had* used cold caches for every run the benefit of the patch
would have looked even better.

Anyway, we should get this upstream to the Xapian folks straight
away. I expect they'll want to see a patch to the chert backend as well
as the flint backend, (but fortunately the relevant code looks very
similar if not identical).

Thanks again,

-Carl


pgpNsIWzmziDM.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[Aneesh Kumar K. V]

On Fri, 04 Dec 2009 11:07:54 -0800, Carl Worth cwo...@cworth.org wrote:
 On Thu,  3 Dec 2009 14:16:44 +0530, Aneesh Kumar K.V 
 aneesh.ku...@linux.vnet.ibm.com wrote:
  From: Aneesh Kumar K.V aneesh.ku...@gmail.com
  
  This patch add --format=sender-only option.
 
 I like the idea here, (and agree that an 'R' keybinding would be great).
 
 But surely there's a way to implement this with dramatically less code
 duplication?

I sent an updated patch which did the above with less code duplication. Any
chance of getting this merged ?

-aneesh
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] reading with multiple MUAs from MailDir

[Roger WANG]

On Fri, 2009-12-11 at 14:11 +0800 Dirk Hohndel wrote:
 
 While playing with notmuch I am still using evolution to read the email
 in the same MailDir that is being indexed / processed by notmuch. With
 the result that lots of emails can not be found in notmuch if they have

I have the similar problem here, and Carl said in IRC There's basically
one feature missing before notmuch will play with another maildir-based
mail reader..

There is also a thread [PATCH] Handle message renames in mail spool in
the archive which might help:

http://notmuchmail.org/pipermail/notmuch/2009/000364.html
http://notmuchmail.org/pipermail/notmuch/2009/000562.html

 been marked as read in evolution between processing in notmuch and
 trying to access them from the user interface.
 
 This makes notmuch /really/ hard to test for me at this point.
 
 Is there a workaround?
 
 /D
 
 

-- 
Roger WANG
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch