[notmuch] [PATCH 2/2] Save all attachments to a directory
{-- Thu, 10 Dec 2009 16:57:01 -0800: Carl wrote: --}
Carl> First, I'm not sure whether we need two different variations of
Carl> what's effectively the same operation here ("save all
Carl> attachments").
Yes, I agree it is an ugly solution. Thanks for not letting me get away
with it. :-)
Carl> What I would like is one command to save a single attachment,
Carl> and then one command to save all attachments. So if we assume
Carl> that the current 'w' keybinding is really for "write one
Carl> attachment" (with a lame implementation currently), and 'W' is
Carl> for "write all attachments", then I think I'd be OK with that.
What do you see as the "write one" behavior for a message with multiple
attachments? I think there needs to be some way to select the
attachment to be written. Maybe we use the prefix-argument for this so
that 'M-2 w' would write the second attachment, 'M-3 w' would write the
third attachment, etc. Since the default is 1, a plain 'w' would write
the first attachment which is the correct default for the single message
case. It's not the most discoverable approach, but it wouldn't be too
bad.
Carl> As for the changes we need here, the prompting for the directory
Carl> needs a string telling the user what's being prompted
Carl> for. Something like "Save all attachments to: ", which should
Carl> just be another argument to the interactive call, right?
Yes, you're right the current approach should have had a proper prompt.
I've been thinking about this though and I wonder if we should skip
separately prompting for the directory and instead do the following:
1) Have customizable "default save directory" both types of attachment
saving default to. Use this as the path part of the prompt for the
filename to which the attachment will be written.
2) After the user has adjusted the path as required, verify that the
full directory path exists and if not create it.
3) Use the same directory path as the default for any subsequent
attachments that are being saved.
This seems like it would lesson the number of keystrokes required for
at least some common cases.
Carl> Second, the command needs to provide a little bit of feedback as
Carl> to what was saved. I ended up running this command a couple of
Carl> times before I realized it was never going to save the inline
Carl> patch with no filename that I was looking at[*].
Carl> So it at least needs to message something like "N files written
Carl> to DIR" or so.
Sure, that's easy to add and makes a lot of sense. We should add
similar error reporting for other common error cases like selecting a
non-existing single attachment to save if we implement the
keystroke-based approach suggested above.
Carl> [*] So there's something else I think we need here. I was seeing
Carl> a patch in a message, but wanted to get it into a file before
Carl> piping it off to something, (so '|' didn't work). The patch
Carl> wasn't an attachment so 'w' didn't work as described above. I
Carl> tried using 'V' to view the raw message, but then found that the
Carl> MIME part I wanted was actually encoded as quoted-printable, so
Carl> just saving the raw message wasn't useful either.
I'm not sure it is the most usable solution, but I believe selecting the
text to save in the rendered message in the thread view and using "M-x
write-region" should handle this use case.
[notmuch] emacs mode performance issue
On Fri, 11 Dec 2009 09:40:23 -0800, Carl Worth wrote: > Which should let you tar these up and you can send them to me privately > and I'll try to replicate and fix the bug. Thanks for passing on the messages, Dirk. If anyone's curious the message that triggered the bug is a public mail on the Linux Kernel Mailing List: id:alpine.LFD.2.00.0912081304070.3560 at localhost.localdomain (It does have to be viewed in thread context---indented at least 13 columns to trigger the bug.) The bug was an infinite loop add the button for a hidden citation, (where our emacs lisp code got a bit confused about where the next line was and infinitely looped on the same citation adding a never ending sequence of "[1-line citation]" buttons). I fixed the infinite loop and while in the area made a few other minor improvements to the citation-hiding code: * No longer consider '>' as introducing a citation if not in first column. * No longer insert an the extra blank line after the citation button. * Add text to the citation button to tell new users that they can click or press Enter on the button to show the citation. I'd still like to add one more feature which is a keybinding to make all the citations for the current message visible. (It could even do the whole thread like the button we used to have, but *only* if it ensured that the current position of point within the current buffer and the current window remained unchanged.) I hope that's helpful, -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/20091211/afdeec21/attachment.pgp>
[notmuch] reading with multiple MUAs from MailDir
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] reading with multiple MUAs from MailDir
On Fri, 11 Dec 2009 12:59:59 -0800, Dirk Hohndel wrote: > With all due respect... Seriously? That doesn't even qualify as a crazy > hack... this process takes something like 15 minutes for me. > > Carl, any idea how when an actual solution to this problem will arrive? Hard to predict, since it depends on me finding some spare time to work on this. It's obviously a high-priority issue for notmuch at this point. In the meantime, Mikhail did contribute a patch that should work, (with some performance impact on "notmuch new"). You might give it try. You can find it in our (lame) web-based archives (with no link to get the raw message), here: http://notmuchmail.org/pipermail/notmuch/2009/000766.html Or if you have all of the notmuch mail archives then you can find it much more easily by just doing a notmuch-search (just hit 's' from any notmuch buffer in emacs) for: id:1259267025-28733-1-git-send-email-dottedmag at dottedmag.net Any latecomers to the list can grab the whole archives from here: http://notmuchmail.org/pipermail/notmuch/2009.txt.gz And import by running that through mb2md (targeting a new directory within the mail store). Eventually I'd like to provide a direct notmuch command for importing an mbox like this. -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/20091211/0666e254/attachment.pgp>
[notmuch] reading with multiple MUAs from MailDir
On Fri, 2009-12-11 at 10:44 +0100, Marten Veldthuis wrote: > Excerpts from Dirk Hohndel's message of Fri Dec 11 07:11:04 +0100 2009: > > Is there a workaround? > > For now, you can do > > notmuch dump somefile > mv Mail/.notmuch /tmp > notmuch new > notmuch restore somefile > > Which will re-index all your mail, and restore your tags, as far as the > messages are still called the same. Deleted messages will disappear from > the library, and moved messages remain in the inbox. > > Still a pain in the ass, but at least it gets rid of all those errors. With all due respect... Seriously? That doesn't even qualify as a crazy hack... this process takes something like 15 minutes for me. Carl, any idea how when an actual solution to this problem will arrive? /D -- Dirk Hohndel Intel Open Source Technology Center
[notmuch] [PATCH -v2] notmuch.el: Support for customizing search result display
On Wed, 2 Dec 2009 18:19:38 +0530, "Aneesh Kumar K.V" wrote:
> From: Aneesh Kumar K.V
>
> This patch helps in customizing search result display
> similar to mutt's index_format. The customization is done
> by defining an alist as below
>
> (setq notmuch-search-result-format '(("date" . "%s ")
>("authors" . "%-40s ")
>("subject" . "%s ")
>("tags" . "(%s)")))
>
> The supported keywords are date, count, authors, subject and tags.
>
Any update on this patch . I would like to get this merged as well
-aneesh
[notmuch] [PATCH 1/2] notmuch-reply: Add support for replying only to sender
On Fri, 04 Dec 2009 11:07:54 -0800, Carl Worth wrote: > On Thu, 3 Dec 2009 14:16:44 +0530, "Aneesh Kumar K.V" linux.vnet.ibm.com> wrote: > > From: Aneesh Kumar K.V > > > > 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] reading with multiple MUAs from MailDir
Excerpts from Dirk Hohndel's message of Fri Dec 11 07:11:04 +0100 2009: > Is there a workaround? For now, you can do notmuch dump somefile mv Mail/.notmuch /tmp notmuch new notmuch restore somefile Which will re-index all your mail, and restore your tags, as far as the messages are still called the same. Deleted messages will disappear from the library, and moved messages remain in the inbox. Still a pain in the ass, but at least it gets rid of all those errors. - Marten -- - Marten
[notmuch] reading with multiple MUAs from MailDir
On Thu, 2009-12-10 at 22: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 > 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. For what it's worth, this drives me nuts, too. Bdale
[notmuch] emacs mode performance issue
On Fri, 11 Dec 2009 08:24:02 -0800, Carl Worth wrote: > In the meantime, if I could get my hands on a message that triggers this > bug, that would be useful. (Here's a case where it would be nice to have > the "notmuch search --output=maildir" command I had talked about so that > we could export the results of a particular search.) Without a nice command to export a search as a maildir, here are some things you can do in the meantime, Dirk. Consider this a free tutorial in using the notmuch command line. First, run a notmuch search to isolate the thread. This might be exactly the search you were using within your notmuch emacs buffer, plus maybe a keyword or two from the subject of the particular thread. So perhaps something like: notmuch search tag:lkml subject:"some phrase here"
[notmuch] emacs mode performance issue
On Thu, 10 Dec 2009 22:10:13 -0800, Dirk Hohndel wrote: > 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? My guess is that it's not a problem of being slow. It sounds much more likely that some of our lame emacs lisp code has gotten itself into an infinite loop. We've got a bunch of silly, ad-hoc code for jumping around the emacs buffer looking for various things. And then we have invisible characters in the emacs buffer which make some of the movement commands behave differently, and unreliably. So there's some ugliness here. The right fix is to move more of the parsing logic into the C code where I can actually comprehend things, and then emit some fully-quoted structure that we can walk with simple, reliable emacs code. In the meantime, if I could get my hands on a message that triggers this bug, that would be useful. (Here's a case where it would be nice to have the "notmuch search --output=maildir" command I had talked about so that we could export the results of a particular search.) -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/20091211/5545a2e7/attachment.pgp>
Re: [notmuch] emacs mode performance issue
On Thu, 10 Dec 2009 22:10:13 -0800, Dirk Hohndel hohn...@infradead.org wrote: 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? My guess is that it's not a problem of being slow. It sounds much more likely that some of our lame emacs lisp code has gotten itself into an infinite loop. We've got a bunch of silly, ad-hoc code for jumping around the emacs buffer looking for various things. And then we have invisible characters in the emacs buffer which make some of the movement commands behave differently, and unreliably. So there's some ugliness here. The right fix is to move more of the parsing logic into the C code where I can actually comprehend things, and then emit some fully-quoted structure that we can walk with simple, reliable emacs code. In the meantime, if I could get my hands on a message that triggers this bug, that would be useful. (Here's a case where it would be nice to have the notmuch search --output=maildir command I had talked about so that we could export the results of a particular search.) -Carl pgp7WIj5GfkCp.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] emacs mode performance issue
On Fri, 11 Dec 2009 08:24:02 -0800, Carl Worth cwo...@cworth.org wrote:
In the meantime, if I could get my hands on a message that triggers this
bug, that would be useful. (Here's a case where it would be nice to have
the notmuch search --output=maildir command I had talked about so that
we could export the results of a particular search.)
Without a nice command to export a search as a maildir, here are some
things you can do in the meantime, Dirk. Consider this a free tutorial
in using the notmuch command line.
First, run a notmuch search to isolate the thread. This might be exactly
the search you were using within your notmuch emacs buffer, plus maybe a
keyword or two from the subject of the particular thread. So perhaps
something like:
notmuch search tag:lkml subject:some phrase here
From that you should be able to see the thread ID of interest, so you
can display the whole thread, (for reading it without hitting the emacs
infinite-loop bug), by just copy-and-paste of the thread ID to notmuch
show:
notmuch show thread:thread-id-here
And at that point you could manually archive the thread with:
notmuch tag -inbox thread:thread-id-here
So that should let you workaround the bug to at least read the thread.
As for debugging, we don't yet have any mechanism in the emacs code to
view a single message without viewing the entire thread, so there's not
an easy way for you to isolate which message is triggering the bug. But
you can at least get the list of filenames from the notmuch show output:
notmuch show thread:thread-id-here | grep message{ | sed
's/.*filename:\(.*\)/\1/'
Which should let you tar these up and you can send them to me privately
and I'll try to replicate and fix the bug.
I hope that's helpful,
-Carl
pgpoFwcRaOwxX.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] reading with multiple MUAs from MailDir
On Fri, 2009-12-11 at 10:44 +0100, Marten Veldthuis wrote: Excerpts from Dirk Hohndel's message of Fri Dec 11 07:11:04 +0100 2009: Is there a workaround? For now, you can do notmuch dump somefile mv Mail/.notmuch /tmp notmuch new notmuch restore somefile Which will re-index all your mail, and restore your tags, as far as the messages are still called the same. Deleted messages will disappear from the library, and moved messages remain in the inbox. Still a pain in the ass, but at least it gets rid of all those errors. With all due respect... Seriously? That doesn't even qualify as a crazy hack... this process takes something like 15 minutes for me. Carl, any idea how when an actual solution to this problem will arrive? /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] reading with multiple MUAs from MailDir
On Fri, 11 Dec 2009 12:59:59 -0800, Dirk Hohndel hohn...@infradead.org wrote: With all due respect... Seriously? That doesn't even qualify as a crazy hack... this process takes something like 15 minutes for me. Carl, any idea how when an actual solution to this problem will arrive? Hard to predict, since it depends on me finding some spare time to work on this. It's obviously a high-priority issue for notmuch at this point. In the meantime, Mikhail did contribute a patch that should work, (with some performance impact on notmuch new). You might give it try. You can find it in our (lame) web-based archives (with no link to get the raw message), here: http://notmuchmail.org/pipermail/notmuch/2009/000766.html Or if you have all of the notmuch mail archives then you can find it much more easily by just doing a notmuch-search (just hit 's' from any notmuch buffer in emacs) for: id:1259267025-28733-1-git-send-email-dotted...@dottedmag.net Any latecomers to the list can grab the whole archives from here: http://notmuchmail.org/pipermail/notmuch/2009.txt.gz And import by running that through mb2md (targeting a new directory within the mail store). Eventually I'd like to provide a direct notmuch command for importing an mbox like this. -Carl pgpQoHkHGVxCa.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] emacs mode performance issue
On Fri, 11 Dec 2009 09:40:23 -0800, Carl Worth cwo...@cworth.org wrote: Which should let you tar these up and you can send them to me privately and I'll try to replicate and fix the bug. Thanks for passing on the messages, Dirk. If anyone's curious the message that triggered the bug is a public mail on the Linux Kernel Mailing List: id:alpine.lfd.2.00.0912081304070.3...@localhost.localdomain (It does have to be viewed in thread context---indented at least 13 columns to trigger the bug.) The bug was an infinite loop add the button for a hidden citation, (where our emacs lisp code got a bit confused about where the next line was and infinitely looped on the same citation adding a never ending sequence of [1-line citation] buttons). I fixed the infinite loop and while in the area made a few other minor improvements to the citation-hiding code: * No longer consider '' as introducing a citation if not in first column. * No longer insert an the extra blank line after the citation button. * Add text to the citation button to tell new users that they can click or press Enter on the button to show the citation. I'd still like to add one more feature which is a keybinding to make all the citations for the current message visible. (It could even do the whole thread like the button we used to have, but *only* if it ensured that the current position of point within the current buffer and the current window remained unchanged.) I hope that's helpful, -Carl pgpV7hIROycq8.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
{-- Thu, 10 Dec 2009 16:57:01 -0800: Carl cwo...@cworth.org wrote: --}
Carl First, I'm not sure whether we need two different variations of
Carl what's effectively the same operation here (save all
Carl attachments).
Yes, I agree it is an ugly solution. Thanks for not letting me get away
with it. :-)
Carl What I would like is one command to save a single attachment,
Carl and then one command to save all attachments. So if we assume
Carl that the current 'w' keybinding is really for write one
Carl attachment (with a lame implementation currently), and 'W' is
Carl for write all attachments, then I think I'd be OK with that.
What do you see as the write one behavior for a message with multiple
attachments? I think there needs to be some way to select the
attachment to be written. Maybe we use the prefix-argument for this so
that 'M-2 w' would write the second attachment, 'M-3 w' would write the
third attachment, etc. Since the default is 1, a plain 'w' would write
the first attachment which is the correct default for the single message
case. It's not the most discoverable approach, but it wouldn't be too
bad.
Carl As for the changes we need here, the prompting for the directory
Carl needs a string telling the user what's being prompted
Carl for. Something like Save all attachments to: , which should
Carl just be another argument to the interactive call, right?
Yes, you're right the current approach should have had a proper prompt.
I've been thinking about this though and I wonder if we should skip
separately prompting for the directory and instead do the following:
1) Have customizable default save directory both types of attachment
saving default to. Use this as the path part of the prompt for the
filename to which the attachment will be written.
2) After the user has adjusted the path as required, verify that the
full directory path exists and if not create it.
3) Use the same directory path as the default for any subsequent
attachments that are being saved.
This seems like it would lesson the number of keystrokes required for
at least some common cases.
Carl Second, the command needs to provide a little bit of feedback as
Carl to what was saved. I ended up running this command a couple of
Carl times before I realized it was never going to save the inline
Carl patch with no filename that I was looking at[*].
Carl So it at least needs to message something like N files written
Carl to DIR or so.
Sure, that's easy to add and makes a lot of sense. We should add
similar error reporting for other common error cases like selecting a
non-existing single attachment to save if we implement the
keystroke-based approach suggested above.
Carl [*] So there's something else I think we need here. I was seeing
Carl a patch in a message, but wanted to get it into a file before
Carl piping it off to something, (so '|' didn't work). The patch
Carl wasn't an attachment so 'w' didn't work as described above. I
Carl tried using 'V' to view the raw message, but then found that the
Carl MIME part I wanted was actually encoded as quoted-printable, so
Carl just saving the raw message wasn't useful either.
I'm not sure it is the most usable solution, but I believe selecting the
text to save in the rendered message in the thread view and using M-x
write-region should handle this use case.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
