Re: tell me how to do this (mass tagging of messages)

2018-12-01 Thread Keith Amidon

On 10/18/18 1:37 AM, Jeff Templon wrote:

I guess the point for me is that I frequently search for messages (and
not threads), and when I do so, it's easy for me to forget that actions
taken on the results buffer not only apply to those messages, they can
apply to all messages in threads that happen to contain a matched
message.


I'm very late to this thread, and ironically not using notmuch to send 
this reply, but I have an additional suggestions to support this use 
case that may still be useful to Jeff or anyone who might find this 
thread through a search of the list archive.


I too frequently search for specific messages, but I use the package 
counsel-notmuch[1] (which was inspired by helm-notmuch[2]) for this 
task. This is relevant to this thread because these packages present a 
view of matching *messages* that updates as you type your query. When 
you select one of the message they take you directly to the selected 
message in notmuch-show-mode instead of the list of threads with 
matching messages in notmuch-search-mode that a regular notmuch search 
does (which is also very useful, but is the less common workflow for 
me). Tagging actions, etc. are then naturally applied to the specific 
message, though I will say that since search works so well this way, I 
use tags fairly infrequently.


Neither project page for these packages makes any attempt to convey how 
awesome it feels to have a filter-as-you-type experience for plucking 
exactly the message from 2 years ago that you're looking for from your 
mail archive with a few seconds of typing, or the looks of incredulity 
you receive from anyone who sees you do it.


And of course, it's all notmuch under the hood making this happen. 
Notmuch is just *awesome*.  :-)


--- Keith

[1] https://github.com/fuxialexander/counsel-notmuch
[2] https://github.com/xuchunyang/helm-notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 6/8] emacs/desktop: update to use notmuch-emacs-mua and handle mailto

2016-11-21 Thread Keith Amidon
On Mon, 2016-11-21 at 13:44 +0200, Jani Nikula wrote:
> I wonder if there's a way to define different Execs for clicking on
> the icon and handling mailto.

The desktop file format specification implies you can just add an extra
context entry.  For reference, the full specification is here:

https://specifications.freedesktop.org/desktop-entry-spec/latest/

Something like this seems like what the spec suggests:

[Desktop Entry]
Name=Notmuch Emacs Client
GenericName=Email Client
Comment=Emacs based email client
Exec=emacs -f notmuch
Icon=emblem-mail
Terminal=false
Type=Application
Categories=Network;Email;

[Create Message]
Name=Notmuch Emacs Create Message
Exec=notmuch-emacs-mua %u
MimeType=x-scheme-handler/mailto;

However, this did not seem to work when I tried it out in my gnome
session.  I'm pretty sure creating two separate desktop files
(duplicating some of the fields) would work.

  --- Keith


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


Re: [PATCH] emacs: add mimetype completions to searches

2016-10-22 Thread Keith Amidon
On Sat, 2016-10-22 at 12:55 +0300, Jani Nikula wrote:
> Any ideas how to get a list of mime types in shell, so I could do the
> same in bash completion without hard-coding some limited list?

Not sure if this is really what you're looking for, but on my archlinux
system, the file /etc/mime.types is installed by a package called mime-
types, which lists this gentoo package as its upstream:

http://packages.gentoo.org/package/app-misc/mime-types

It's pulled in as a dependency of installing firefox, so presumably
some version of this is pretty ubiquitous on Linux systems.

  --- Keith


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


[PATCH] Expand docstrings about fcc using notmuch-insert

2016-10-19 Thread Keith Amidon
This commit expands docstrings for notmuch-fcc-dirs and
notmuch-maildir-fcc-with-notmuch-insert to describe how quoted strings
are processed and make the ability to configure sent folders containing
whitespace more discoverable.
---
 emacs/notmuch-maildir-fcc.el | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index 95e5650..ea75bb9 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -54,7 +54,10 @@ If `notmuch-maildir-use-notmuch-insert' is set (the default) 
then
 the header should be of the form \"folder +tag1 -tag2\" where
 folder is the folder (relative to the notmuch mailstore) to store
 the message in, and tag1 and tag2 are tag changes to apply to the
-stored message.
+stored message. This string is split using `split-string-and-unquote',
+so a folder name containing spaces can be specified by
+quoting each space with an immediately preceding backslash
+or surrounding the entire folder name in double quotes.
 
 If `notmuch-maildir-use-notmuch-insert' is nil then the Fcc
 header should be the directory where the message should be
@@ -230,8 +233,12 @@ should be a list of tag changes to apply to the inserted 
message."
 The fcc-header should be of the form \"folder +tag1 -tag2\" where
 folder is the folder (relative to the notmuch mailstore) to store
 the message in, and tag1 and tag2 are tag changes to apply to the
-stored message. If CREATE is non-nil then create the folder if
-necessary."
+stored message. This string is split using `split-string-and-unquote',
+so a folder name containing spaces can be specified by
+quoting each space with an immediately preceding backslash
+or surrounding the entire folder name in double quotes.
+
+If CREATE is non-nil then create the folder if necessary."
   (let* ((args (split-string-and-unquote fcc-header))
 (folder (car args))
 (tags (cdr args)))
-- 
2.10.0

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


[PATCH v2] Expand docstrings about fcc using notmuch-insert

2016-10-19 Thread Keith Amidon

Tnis version implements Mark's second, simpler, suggestion.  Since
the reference to split-string-and-unquote remains, someone with
sufficiently esoteric requirements will know where to look to
determine exactly what is possible.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] Expand docstrings about fcc using notmuch-insert

2016-10-10 Thread Keith Amidon
This commit expands docstrings for notmuch-fcc-dirs and
notmuch-maildir-fcc-with-notmuch-insert to describe how quoted strings
are processed and make the ability to configure sent folders containing
whitespace more discoverable.
---
 emacs/notmuch-maildir-fcc.el | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index 95e5650..cfe1931 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -54,7 +54,10 @@ If `notmuch-maildir-use-notmuch-insert' is set (the default) 
then
 the header should be of the form \"folder +tag1 -tag2\" where
 folder is the folder (relative to the notmuch mailstore) to store
 the message in, and tag1 and tag2 are tag changes to apply to the
-stored message.
+stored message.  This string is split using `split-string-and-unquote',
+so a folder name containing whitespace can be specified by
+quoting the whitespace with an immediately preceeding backslash
+or surrounding the entire folder name in double quotes.
 
 If `notmuch-maildir-use-notmuch-insert' is nil then the Fcc
 header should be the directory where the message should be
@@ -230,8 +233,12 @@ should be a list of tag changes to apply to the inserted 
message."
 The fcc-header should be of the form \"folder +tag1 -tag2\" where
 folder is the folder (relative to the notmuch mailstore) to store
 the message in, and tag1 and tag2 are tag changes to apply to the
-stored message. If CREATE is non-nil then create the folder if
-necessary."
+stored message. This string is split using `split-string-and-unquote',
+so a folder name containing whitespace can be specified by quoting
+the whitespace with an immediately preceeding backslash or
+surrounding the entire folder name in double quotes.
+
+If CREATE is non-nil then create the folder if necessary."
   (let* ((args (split-string-and-unquote fcc-header))
 (folder (car args))
 (tags (cdr args)))
-- 
2.10.0

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


Re: notmuch-insert Fcc handling w/spaces in dir name

2016-10-10 Thread Keith Amidon
On Mon, 2016-10-10 at 20:20 +0100, Mark Walters wrote:
> On Mon, 10 Oct 2016, Keith Amidon <cama...@picnicpark.org> wrote:
> > 
> > I was able to make this work by setting notmuch-fcc-dirs to:
> > 
> >    "\"[Gmail]/Sent Mail\" +sent -inbox -unread"
> 
> That is correct and this should probably be documented.

After Mark and Tomi's hints I read the code more closely and really
understand why my setting actually works and why this is actually an
intended behavior.  Given that it doesn't actually depend on passing
through the shell quoting, supports oddball folder names with spaces in
them, and makes it easy to continue to support sender-based Fcc
selection (which I also expect to want to use eventually), I'm happy
with it as is.

I'll send a suggested documentation patch to the list to make it easier
to discover the behavior shortly.

      Thanks for the help!    --- Keith
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


notmuch-insert Fcc handling w/spaces in dir name

2016-10-10 Thread Keith Amidon
I just upgraded to 0.23 and tried out the Fcc handling using notmuch-
insert.  I think this is a significant improvement and I'm excited to
use it.   I have it working successfully for my use case now, but it
did require one workaround that I didn't expect and that seems somewhat
fragile.

The issue is that I'm synchronizing with Gmail and I'd like my sent
mail to be synchronized too.  Therefore I have to insert into the
directory Gmail expects, which is "[Gmail]/Sent Mail".  Notice the
space in the directory name.

I was able to make this work by setting notmuch-fcc-dirs to:

   "\"[Gmail]/Sent Mail\" +sent -inbox -unread"

This works because the Fcc handling constructs a shell command to run
by just appending the notmuch-fcc-dirs value to (in the simple case)
"notmuch-insert --folder=", so the extra double quotes in my notmuch-
fcc-dirs value quote things appropriately at the shell level.

While this works, depending on passing through shell quoting seems very
fragile.  Changes in the implementation could break this solution
without it being obvious why.  It seems like it would be better if the
notmuch-fcc-dirs value could be something like:

    ("[Gmail]/Sent Mail" "+sent" "-inbox" "-unread")

Then the code could generate the shell command with appropriate
quoting.  I took a quick look at implementing this but it looked more
complicated then I had time to invested right now.  I thought it would
be good to get the issue out for discussion ASAP since this new
functionality was just released.

      Cheers!   Keith


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


Do path: searches handle spaces correctly?

2014-09-22 Thread Keith Amidon
On Mon, 2014-09-22 at 15:06 +, Austin Clements wrote:
> I assume you're doing this from the command line?  Does the following
> work?
> 
> notmuch search --output=files 'path:"dir/INBOX/INBOX/Sent Items/**"'
> 
> Shell quoting and Xapian quoting interact in often confusing ways.  In
> your original command line, the single quotes suppress shell argument
> splitting, but never make it to notmuch, so notmuch sees two search
> terms "path:dir/INBOX/INBOX/Sent" and "Items/**".  In the command line
> I suggested, the single quotes play the same role, but for the entire
> query.  Because of the quoting, notmuch *does* see the inner double
> quotes, which makes the path a single term (note that Xapian only
> accepts double quotes, not single quotes).  In general, it's good to
> enclose the entire command line query in single quotes so shell
> parsing doesn't get in the way of query parsing.

Bingo.  That was it.  Thanks for clarifying how the quoting interacts. 

What do you think about adding a section to the notmuch-search-terms web
page that talks in more detail about the quoting interactions?  If there
were on obvious section about this in the man page it might have helped
me find the issue myself.  If this seems like a good idea I'll take a
crack at it later this week when I get time to research the Xapian
quoting in a bit more detail.

--- Keith



Do path: searches handle spaces correctly?

2014-09-22 Thread Keith Amidon
On Mon, 2014-09-22 at 11:20 +0200, David Bremner wrote:
> Keith Amidon  writes:
> >
> > notmuch search --output=files path:'dir/INBOX/INBOX/Sent Items'
> >
> > I don't get any results, but it seems like the two results above should
> > be shown, right?  Am I doing something wrong here?  If it looks like I'm
> > doing it correctly, what can I do to help troubleshoot the issue?
> 
> Note that path:, unlike folder:, does not add the maildir subdirs. Dunno
> if that's the only issue you are having, but I guess it's one.

Darn it!  I made a mistake in my original email.  In the test I was
doing I actually had:

notmuch search --output=files path:'dir/INBOX/INBOX/Sent Items/**'

which I believe should have picked up all the subdirectory paths.  I
just retested to make sure that it still didn't work, and it doesn't.

Am I still missing something?   Thanks for the help, Keith




Do path: searches handle spaces correctly?

2014-09-22 Thread Keith Amidon
I'm trying to update an archiving tool that used the old folder: search
terms to use the newer folder: or path: terms.  From playing around with
it, I think that the path: term is what I want to use.  However, I am
getting some behavior I don't understand unless path: searches don't
properly handle spaces or I don't know how to quote them properly.

If I do:

notmuch search --output=files path:'dir/INBOX/**'

I get:

base/dir/INBOX/cur/1411244319_3.18990.kea-tablet,U=24,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
base/dir/INBOX/cur/1411244319_2.18990.kea-tablet,U=23,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
base/dir/INBOX/INBOX/Sent 
Items/cur/1411244324_2.18990.kea-tablet,U=3,FMD5=e99e6ef6cc1489bb6d8b47a4c49bb989:2,S
base/dir/INBOX/cur/1411244319_1.18990.kea-tablet,U=22,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,RS
base/dir/INBOX/cur/1411244319_0.18990.kea-tablet,U=21,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
base/dir/INBOX/cur/1411244318_3.18990.kea-tablet,U=20,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
base/dir/INBOX/cur/1411244318_2.18990.kea-tablet,U=19,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
base/dir/INBOX/cur/1411244318_1.18990.kea-tablet,U=18,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
base/dir/INBOX/INBOX/Sent 
Items/cur/1411244324_1.18990.kea-tablet,U=2,FMD5=e99e6ef6cc1489bb6d8b47a4c49bb989:2,S
base/dir/INBOX/cur/1411244318_0.18990.kea-tablet,U=17,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S

Notice that this contains results for dir/INBOX/INBOX/Sent Items,
which has a space in it.  If I do:

notmuch search --output=files path:'dir/INBOX/INBOX/Sent Items'

I don't get any results, but it seems like the two results above should
be shown, right?  Am I doing something wrong here?  If it looks like I'm
doing it correctly, what can I do to help troubleshoot the issue?

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


Re: Do path: searches handle spaces correctly?

2014-09-22 Thread Keith Amidon
On Mon, 2014-09-22 at 15:06 +, Austin Clements wrote:
 I assume you're doing this from the command line?  Does the following
 work?
 
 notmuch search --output=files 'path:dir/INBOX/INBOX/Sent Items/**'
 
 Shell quoting and Xapian quoting interact in often confusing ways.  In
 your original command line, the single quotes suppress shell argument
 splitting, but never make it to notmuch, so notmuch sees two search
 terms path:dir/INBOX/INBOX/Sent and Items/**.  In the command line
 I suggested, the single quotes play the same role, but for the entire
 query.  Because of the quoting, notmuch *does* see the inner double
 quotes, which makes the path a single term (note that Xapian only
 accepts double quotes, not single quotes).  In general, it's good to
 enclose the entire command line query in single quotes so shell
 parsing doesn't get in the way of query parsing.

Bingo.  That was it.  Thanks for clarifying how the quoting interacts. 

What do you think about adding a section to the notmuch-search-terms web
page that talks in more detail about the quoting interactions?  If there
were on obvious section about this in the man page it might have helped
me find the issue myself.  If this seems like a good idea I'll take a
crack at it later this week when I get time to research the Xapian
quoting in a bit more detail.

--- Keith

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


Do path: searches handle spaces correctly?

2014-09-20 Thread Keith Amidon
I'm trying to update an archiving tool that used the old folder: search
terms to use the newer folder: or path: terms.  From playing around with
it, I think that the path: term is what I want to use.  However, I am
getting some behavior I don't understand unless path: searches don't
properly handle spaces or I don't know how to quote them properly.

If I do:

notmuch search --output=files path:'dir/INBOX/**'

I get:

/dir/INBOX/cur/1411244319_3.18990.kea-tablet,U=24,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
/dir/INBOX/cur/1411244319_2.18990.kea-tablet,U=23,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
/dir/INBOX/INBOX/Sent 
Items/cur/1411244324_2.18990.kea-tablet,U=3,FMD5=e99e6ef6cc1489bb6d8b47a4c49bb989:2,S
/dir/INBOX/cur/1411244319_1.18990.kea-tablet,U=22,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,RS
/dir/INBOX/cur/1411244319_0.18990.kea-tablet,U=21,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
/dir/INBOX/cur/1411244318_3.18990.kea-tablet,U=20,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
/dir/INBOX/cur/1411244318_2.18990.kea-tablet,U=19,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
/dir/INBOX/cur/1411244318_1.18990.kea-tablet,U=18,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
/dir/INBOX/INBOX/Sent 
Items/cur/1411244324_1.18990.kea-tablet,U=2,FMD5=e99e6ef6cc1489bb6d8b47a4c49bb989:2,S
/dir/INBOX/cur/1411244318_0.18990.kea-tablet,U=17,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S

Notice that this contains results for "dir/INBOX/INBOX/Sent Items",
which has a space in it.  If I do:

notmuch search --output=files path:'dir/INBOX/INBOX/Sent Items'

I don't get any results, but it seems like the two results above should
be shown, right?  Am I doing something wrong here?  If it looks like I'm
doing it correctly, what can I do to help troubleshoot the issue?

 Thanks, Keith


sending email using different server for different 'From:' field

2014-09-02 Thread Keith Amidon
On Tue, 2014-09-02 at 14:26 +0200, David Belohrad wrote:
> could that scenario be somehow fitted automatically, so when I overwrite
> the default 'From:' address (by hand. is it possible to do some
> automatic cycling?) to work address, so that message sender in emacs
> would automatically use work exchange server to deliver the mail?

I think this is more of a message-mode question than a notmuch question.
I use something very similar to code attached below, which is rather
brute-force, but does the job for me.

 --- Keith

-

(defun kea/send-mail-with-x ()
  (interactive)
  (setq smtpmail-smtp-server "smtp.x.com"
smtpmail-smtp-service 587
smtpmail-local-domain "x.com"
smtpmail-auth-user nil
smtpmail-stream-type 'starttls))

(defun kea/send-mail-with-y ()
  (interactive)
  (setq smtpmail-smtp-server "email.y.com"
smtpmail-smtp-service 587
smtpmail-local-domain "y.com"
smtpmail-auth-user nil
smtpmail-stream-type 'starttls))

(defun kea/message-select-mail-dest ()
  (cond ((string-match ""
   (message-field-value "From"))
 (kea/send-mail-with-x))
(t
 (kea/send-mail-with-y

(kea/send-mail-with-y)
(add-hook 'message-send-hook 'kea/message-select-mail-dest)





Re: sending email using different server for different 'From:' field

2014-09-02 Thread Keith Amidon
On Tue, 2014-09-02 at 14:26 +0200, David Belohrad wrote:
 could that scenario be somehow fitted automatically, so when I overwrite
 the default 'From:' address (by hand. is it possible to do some
 automatic cycling?) to work address, so that message sender in emacs
 would automatically use work exchange server to deliver the mail?

I think this is more of a message-mode question than a notmuch question.
I use something very similar to code attached below, which is rather
brute-force, but does the job for me.

 --- Keith

-

(defun kea/send-mail-with-x ()
  (interactive)
  (setq smtpmail-smtp-server smtp.x.com
smtpmail-smtp-service 587
smtpmail-local-domain x.com
smtpmail-auth-user nil
smtpmail-stream-type 'starttls))

(defun kea/send-mail-with-y ()
  (interactive)
  (setq smtpmail-smtp-server email.y.com
smtpmail-smtp-service 587
smtpmail-local-domain y.com
smtpmail-auth-user nil
smtpmail-stream-type 'starttls))

(defun kea/message-select-mail-dest ()
  (cond ((string-match k...@x.com
   (message-field-value From))
 (kea/send-mail-with-x))
(t
 (kea/send-mail-with-y

(kea/send-mail-with-y)
(add-hook 'message-send-hook 'kea/message-select-mail-dest)



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


[notmuch] [PATCH] Rework saving of attachments.

2010-02-24 Thread Keith Amidon
Resending to the list as well as just Carl...

{-- Tue, 23 Feb 2010 11:12:36 -0800: Carl  wrote: --}
  Carl> I apologize for the extraordinarly-late review, but here it
  Carl> is...

No problem at all.  You're updates on status have been sufficient to
convince me you were making progress and would get to everything
eventually and I've not exactly had any significant time to be playing
with notmuch  code anyway.  :-)

  Carl> I tried this patch out, wanted to like it, and almost pushed it
  Carl> out, but I decided against it in its current form. Here are some
  Carl> thoughts:

  Carl> 1. The commit message ("rework saving of attachments") is not
  Carl> adequate

Sure, I can make more granular commits.  Much of the work in this one
was inter-related in that my goal for the behavior couldn't be tested
until most of the work was done and I didn't take much care to commit
interim steps due to an over-eagerness to complete the changes. Easily
correctable.

  Carl> 2. A binding to save a single attachment (with only a prefix
  Carl> argument to select which) just isn't usable. 

Yes, I agree the current implementation for the save single attachment
is not the best.

  Carl> First, there's nothing in the UI to indicate the appropriate
  Carl> numbers to pass as the prefix argument, (other than manually
  Carl> counting the attachments). 

This is the real problem in my opinion.  My plan, which I've had no time
to implement, was to do something similar to what Gnus does; make a
button for each part and in the button text include the number of each
part.  This way the user would no longer have to manually count.

  Carl> And second, the functionality is simply too hidden and
  Carl> non-obvious. This is most dangerous because in the common case
  Carl> of a single attachment, the 'w' binding will seem to be saving
  Carl> all attachments setting up confusion if the user tries to save
  Carl> multiple attachments with this same keybinding.

  Carl>Now, having a function to save a single attachment is just
  Carl> fine, (leaving someone else to hook up a binding to a particular
  Carl> button, say). So I'd accept a patch that added that, but didn't
  Carl> add a direct key-binding for it.

I personally think that there should be a key-binding that allows saving
individual attachments and doesn't require navigating to a button in the
message and then doing something.  There are key-bindings in Gnus to do
this that I use all the time and I think notmuch should support
something similar.  Maybe the right approach is to combine both
functions on a single key-binding for example if no prefix argument is
given all attachments are saved and a prefix selects the specific
attachment.  

  Carl> 3. For saving multiple attachments, the feature I'd really like
  Carl> to see is the ability to specify a single directory and have all
  Carl> the attachments saved there.

I think the current code does support this functionality, although it
may not be completely obvious.  It adds a default directory in which to
save attachments (notmuch-default-save-dir).  When you type 'W' to save
all attachments it prompts for the location to save the first attachment
with a path built from the combination of notmuch-default-save-dir and
the filename or description of the attachment.  You can edit this path
to your heart's content.  Any subsequent attachments to be saved will
default to the directory into which you saved the most recent
attachment.

In use, if you want all attachments saved to the default directory with
their default filenames all you have to do is hit 'W' followed by one
carriage return per attachment.  If you want all of them saved to the
same directory but different from the default save directory you hit 'W'
edit the first path, then hit enter for each subsequent attachment.  The
changes support creating the destination directory path if it is not
already there.

  Carl> Obviously, this third feature is just something different than
  Carl> what the patch does, so not necessarily a reason to reject the
  Carl> patch. So what is it that the patch actually does again?

  Carl> I think the big advantage of the patch is getting rid of the
  Carl> initial prompting "save this attachment (foo)?". It occurs to me
  Carl> that a simpler way to get rid of that would be to simply not ask
  Carl> that question when the user hits 'w' and there *is* only a
  Carl> single attachment. Then, with multiple attachments, 'w' could
  Carl> prompt in turn as currently.

In my mind the key advantage of the patch was the much improved behavior
of the 'W' keybinding, described above.  Maybe that just wasn't obvious?

  Carl> That would leave open the ability to use 'W' for a command to
  Carl> write all attachments to a particular directory.

For this are you imagining that the user would first be prompted for the
directory in which to save the attachments and then all attachments
would be saved with some set of default names and no need 

Re: [notmuch] [PATCH] Rework saving of attachments.

2010-02-24 Thread Keith Amidon
Resending to the list as well as just Carl...

{-- Tue, 23 Feb 2010 11:12:36 -0800: Carl cwo...@cworth.org wrote: --}
  Carl I apologize for the extraordinarly-late review, but here it
  Carl is...

No problem at all.  You're updates on status have been sufficient to
convince me you were making progress and would get to everything
eventually and I've not exactly had any significant time to be playing
with notmuch  code anyway.  :-)

  Carl I tried this patch out, wanted to like it, and almost pushed it
  Carl out, but I decided against it in its current form. Here are some
  Carl thoughts:

  Carl 1. The commit message (rework saving of attachments) is not
  Carl adequate

Sure, I can make more granular commits.  Much of the work in this one
was inter-related in that my goal for the behavior couldn't be tested
until most of the work was done and I didn't take much care to commit
interim steps due to an over-eagerness to complete the changes. Easily
correctable.

  Carl 2. A binding to save a single attachment (with only a prefix
  Carl argument to select which) just isn't usable. 

Yes, I agree the current implementation for the save single attachment
is not the best.

  Carl First, there's nothing in the UI to indicate the appropriate
  Carl numbers to pass as the prefix argument, (other than manually
  Carl counting the attachments). 

This is the real problem in my opinion.  My plan, which I've had no time
to implement, was to do something similar to what Gnus does; make a
button for each part and in the button text include the number of each
part.  This way the user would no longer have to manually count.

  Carl And second, the functionality is simply too hidden and
  Carl non-obvious. This is most dangerous because in the common case
  Carl of a single attachment, the 'w' binding will seem to be saving
  Carl all attachments setting up confusion if the user tries to save
  Carl multiple attachments with this same keybinding.

  CarlNow, having a function to save a single attachment is just
  Carl fine, (leaving someone else to hook up a binding to a particular
  Carl button, say). So I'd accept a patch that added that, but didn't
  Carl add a direct key-binding for it.

I personally think that there should be a key-binding that allows saving
individual attachments and doesn't require navigating to a button in the
message and then doing something.  There are key-bindings in Gnus to do
this that I use all the time and I think notmuch should support
something similar.  Maybe the right approach is to combine both
functions on a single key-binding for example if no prefix argument is
given all attachments are saved and a prefix selects the specific
attachment.  

  Carl 3. For saving multiple attachments, the feature I'd really like
  Carl to see is the ability to specify a single directory and have all
  Carl the attachments saved there.

I think the current code does support this functionality, although it
may not be completely obvious.  It adds a default directory in which to
save attachments (notmuch-default-save-dir).  When you type 'W' to save
all attachments it prompts for the location to save the first attachment
with a path built from the combination of notmuch-default-save-dir and
the filename or description of the attachment.  You can edit this path
to your heart's content.  Any subsequent attachments to be saved will
default to the directory into which you saved the most recent
attachment.

In use, if you want all attachments saved to the default directory with
their default filenames all you have to do is hit 'W' followed by one
carriage return per attachment.  If you want all of them saved to the
same directory but different from the default save directory you hit 'W'
edit the first path, then hit enter for each subsequent attachment.  The
changes support creating the destination directory path if it is not
already there.

  Carl Obviously, this third feature is just something different than
  Carl what the patch does, so not necessarily a reason to reject the
  Carl patch. So what is it that the patch actually does again?

  Carl I think the big advantage of the patch is getting rid of the
  Carl initial prompting save this attachment (foo)?. It occurs to me
  Carl that a simpler way to get rid of that would be to simply not ask
  Carl that question when the user hits 'w' and there *is* only a
  Carl single attachment. Then, with multiple attachments, 'w' could
  Carl prompt in turn as currently.

In my mind the key advantage of the patch was the much improved behavior
of the 'W' keybinding, described above.  Maybe that just wasn't obvious?

  Carl That would leave open the ability to use 'W' for a command to
  Carl write all attachments to a particular directory.

For this are you imagining that the user would first be prompted for the
directory in which to save the attachments and then all attachments
would be saved with some set of default names and no need for further

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

2009-12-11 Thread Keith Amidon
{-- 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.



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

2009-12-11 Thread Keith Amidon
{-- 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


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

2009-12-07 Thread Keith Amidon
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.

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

1) It first prompts for the directory in which to save attachments
   instead of assuming the current default directory.

2) If there is more than one attachment in the message, it assumes all
   should be saved and only prompts for filenames instead of asking
   first whether each attachment should be saved.
---
 notmuch.el |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 8d51709..08bd114 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -65,6 +65,7 @@
 (define-key map r 'notmuch-show-reply)
 (define-key map | 'notmuch-show-pipe-message)
 (define-key map w 'notmuch-show-save-attachments)
+(define-key map W 'notmuch-show-save-all-attachments)
 (define-key map V 'notmuch-show-view-raw-message)
 (define-key map v 'notmuch-show-view-all-mime-parts)
 (define-key map - 'notmuch-show-remove-tag)
@@ -352,6 +353,17 @@ buffer.
   mm-handle ( (notmuch-count-attachments mm-handle) 1
   (message Done))
 
+(defun notmuch-show-save-all-attachments (directory)
+  Save all attachments of a message to a directory.
+  (interactive G)
+  (let ((dirname (file-name-as-directory directory)))
+(make-directory dirname t)
+(with-current-notmuch-show-message
+ (let ((mm-handle (mm-dissect-buffer))
+   (mm-default-directory dirname))
+   (notmuch-save-attachments mm-handle nil
+  (message Done))
+
 (defun notmuch-reply (query-string)
   (switch-to-buffer (generate-new-buffer notmuch-draft))
   (call-process notmuch-command nil t nil reply query-string)
-- 
1.6.5.4

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


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

2009-12-05 Thread Keith Amidon
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.

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

1) It first prompts for the directory in which to save attachments
   instead of assuming the current default directory.

2) If there is more than one attachment in the message, it assumes all
   should be saved and only prompts for filenames instead of asking
   first whether each attachment should be saved.
---
 notmuch.el |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 8d51709..08bd114 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -65,6 +65,7 @@
 (define-key map "r" 'notmuch-show-reply)
 (define-key map "|" 'notmuch-show-pipe-message)
 (define-key map "w" 'notmuch-show-save-attachments)
+(define-key map "W" 'notmuch-show-save-all-attachments)
 (define-key map "V" 'notmuch-show-view-raw-message)
 (define-key map "v" 'notmuch-show-view-all-mime-parts)
 (define-key map "-" 'notmuch-show-remove-tag)
@@ -352,6 +353,17 @@ buffer."
   mm-handle (> (notmuch-count-attachments mm-handle) 1
   (message "Done"))

+(defun notmuch-show-save-all-attachments (directory)
+  "Save all attachments of a message to a directory."
+  (interactive "G")
+  (let ((dirname (file-name-as-directory directory)))
+(make-directory dirname t)
+(with-current-notmuch-show-message
+ (let ((mm-handle (mm-dissect-buffer))
+   (mm-default-directory dirname))
+   (notmuch-save-attachments mm-handle nil
+  (message "Done"))
+
 (defun notmuch-reply (query-string)
   (switch-to-buffer (generate-new-buffer "notmuch-draft"))
   (call-process notmuch-command nil t nil "reply" query-string)
-- 
1.6.5.4



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

2009-12-05 Thread Keith Amidon
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.
---
 notmuch.el |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index c504f46..8d51709 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -322,7 +322,9 @@ buffer."
  (lambda (p)
(let ((disposition (mm-handle-disposition p)))
  (and (listp disposition)
-  (equal (car disposition) "attachment")
+  (or (equal (car disposition) "attachment")
+  (and (equal (car disposition) "inline")
+   (assq 'filename disposition)))
   (incf count
  mm-handle)
 count))
@@ -332,7 +334,9 @@ buffer."
(lambda (p)
  (let ((disposition (mm-handle-disposition p)))
(and (listp disposition)
-(equal (car disposition) "attachment")
+(or (equal (car disposition) "attachment")
+(and (equal (car disposition) "inline")
+ (assq 'filename disposition)))
 (or (not queryp)
 (y-or-n-p
  (concat "Save '" (cdr (assq 'filename disposition)) "' ")))
-- 
1.6.5.4



[notmuch] Simple improvements to saving attachments

2009-12-05 Thread Keith Amidon
I found there were some attachments I couldn't save using the existing
functionality.  Since I was already touching the code I implemented a
rough cut at the "save all attachments" function Carl requested as
well.

I don't think this is the best code in the world but it gets the job
done for now and I expect it will get replaced with something much
better when some more thought has been put into the split in
mime-handling functionality between the frontend and the backend.

   --- Keith



[notmuch] [PATCH 6/9] Reply to individual messages using message library

2009-11-28 Thread Keith Amidon
{-- Fri, 27 Nov 2009 21:22:36 -0800: Carl  wrote: --}


  Carl> On Fri, 27 Nov 2009 05:30:12 -0800, camalot at picnicpark.org wrote:
  >> From: Keith Amidon 
  >> 
  >> As an alternative to creating a reply from the current thread, this
  >> commit provides functions to create replies directly in emacs using
  >> the message library.
  >> 
  >> A future commit will provide keybindings so that they are easy to
  >> change if a different set is preferred.

  Carl> Can you fill me in a little bit here? The message-mode
  Carl> documentation is quite thin on what the distinctions are between
  Carl> "reply", "wide-reply", and "followup".

Roughly this is my understanding of the
differences:

   reply: reply only to the sender and no other recipients
   wide reply: reply to all recipients (removing self)
   followup: mainly intended for replying to news articles I believe is
the trigger for the Mail-Followup-To behavior.  See:


http://www.gnu.org/software/emacs/manual/html_node/message/Mailing-Lists.html#Mailing-Lists

  Carl> Meanwhile, I don't think we have any need to support different
  Carl> implementations of reply, (that is---I don't want one binding
  Carl> for a "notmuch-based reply" and another for a
  Carl> "message-mode-based reply" without any functional difference in
  Carl> the result).

I agree.  It wasn't clear to me when each type of behavior was useful
and so I erred on the side of making everything available with long
key bindings with the idea that as it became clear what was most useful
the common short key bindings could get those functions.

  Carl> Instead I'd like to define what the functionality is that we
  Carl> want here, and then provide that. I do like taking advantage of
  Carl> things like message-mode functionality wherever it exists, so
  Carl> I'm happy to have the default reply button do
  Carl> (with-current-notmuch-show-message (message-reply)) or whatever.

  Carl> But meanwhile, I'll *also* want to understand what the
  Carl> variations are here so that we can *also* implement them inside
  Carl> of "notmuch reply" so that non-emacs-based interfaces can easily
  Carl> get at similar functionality.

  Carl> So I'm holding off on pushing this patch until I understand it
  Carl> better, (and documentation strings for the new functions might
  Carl> help for that---provided they have more detail than the
  Carl> corresponding documentation strings for the message-mode
  Carl> functions being called).

I'll try to improve my docstings next time around.  Sorry about that!

--- Keith


[notmuch] [PATCH 5/9] Forward individual messages using message-forward

2009-11-28 Thread Keith Amidon
{-- Sat, 28 Nov 2009 09:49:58 -0800: Carl  wrote: --}
  Carl> So when there are quick and easy things, (like calling an
  Carl> existing function on an 'f' binding like above), that totally
  Carl> makes sense to do. We can look at things like that as interim
  Carl> solutions until the C program grows up.

  Carl> Long-term, I do expect a lot of features to end up being
  Carl> implemented in the C program.

Thanks for your perspective on the best place for things to be
implemented.  I like the pragmatism of using what's easily available in
emacs now and moving to using functions provided by the C implementation
as they become available in the future.  

Since I have relatively limited time right now, I'll probably be a lot
more productive hacking elisp code.  I won't get too attached to that
code though... :-)

--- Keith





[notmuch] [PATCH 5/9] Forward individual messages using message-forward

2009-11-28 Thread Keith Amidon
{-- Fri, 27 Nov 2009 21:15:15 -0800: Carl  wrote: --}


  Carl> On Fri, 27 Nov 2009 05:30:11 -0800, camalot at picnicpark.org wrote:
  >> From: Keith Amidon 
  >> Sometimes forwarding a message is preferable to replying and
  >> modifying the set of recipients.  This commit provides that ability
  >> using the message-forward function.

  Carl> This is nice functionality---we were obviously missing a
  Carl> "forward" command before. So I've pushed this.

Thanks.

  Carl> Meanwhile, this does miss one piece of functionality that we
  Carl> have in "notmuch reply" which is to select the From: address
  Carl> based on which configured email address of the user was found in
  Carl> the recipient list of the original message being forwarded.

  Carl> Any suggestion for this functionality? Does message-mode provide
  Carl> something similar? And if so, should notmuch.el simply read the
  Carl> notmuch configuration for the various email addresses and
  Carl> provide them to message-mode? I definitely don't want new users
  Carl> of notmuch to have to configure email addresses both inside of
  Carl> notmuch and also inside of message-mode, for example.

I'm sure message-mode can be tweaked either gracefully or savagely in
order to provide this.  I'd be happy to look into it although I
unfortunately don't have a lot of time to code right now. 

What are your thoughts generally about integration with things like
message mode vs. implementing more into the C program?  If you think the
message-mode enhancements will have a life I'll spend some time on this
and getting the semi-broken version of the reply functions I posted
working more correctly as well.

   --- Keith





[notmuch] [PATCH 2/9] Adjust autoload comments

2009-11-28 Thread Keith Amidon
{-- Fri, 27 Nov 2009 21:06:45 -0800: Carl  wrote: --}

  Carl> On Fri, 27 Nov 2009 05:30:08 -0800, camalot at picnicpark.org wrote:
  Carl> I had a patch (on a side branch that I must have never merged)
  Carl> that just removed these autoload comments. Do these even do
  Carl> anything for a file that's not being built along with all the
  Carl> lisp code within emacs?

I was interested in them because the gentoo packaging support for emacs
includes the ability to automatically create autoloads from these
comments for installed add-on packages that then get loaded system-wide
when emacs is started.  

I've my own ebuild using this functionality right now that is just
slightly different from the one that was posted here a little while ago.
I've been meaning to merge my version with that one but haven't gotten
to it yet.

   --- Keith



Re: [notmuch] [PATCH 2/9] Adjust autoload comments

2009-11-28 Thread Keith Amidon
{-- Fri, 27 Nov 2009 21:06:45 -0800: Carl cwo...@cworth.org wrote: --}

  Carl On Fri, 27 Nov 2009 05:30:08 -0800, cama...@picnicpark.org wrote:
  Carl I had a patch (on a side branch that I must have never merged)
  Carl that just removed these autoload comments. Do these even do
  Carl anything for a file that's not being built along with all the
  Carl lisp code within emacs?

I was interested in them because the gentoo packaging support for emacs
includes the ability to automatically create autoloads from these
comments for installed add-on packages that then get loaded system-wide
when emacs is started.  

I've my own ebuild using this functionality right now that is just
slightly different from the one that was posted here a little while ago.
I've been meaning to merge my version with that one but haven't gotten
to it yet.

   --- Keith

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


Re: [notmuch] [PATCH 5/9] Forward individual messages using message-forward

2009-11-28 Thread Keith Amidon
{-- Sat, 28 Nov 2009 09:49:58 -0800: Carl cwo...@cworth.org wrote: --}
  Carl So when there are quick and easy things, (like calling an
  Carl existing function on an 'f' binding like above), that totally
  Carl makes sense to do. We can look at things like that as interim
  Carl solutions until the C program grows up.

  Carl Long-term, I do expect a lot of features to end up being
  Carl implemented in the C program.

Thanks for your perspective on the best place for things to be
implemented.  I like the pragmatism of using what's easily available in
emacs now and moving to using functions provided by the C implementation
as they become available in the future.  

Since I have relatively limited time right now, I'll probably be a lot
more productive hacking elisp code.  I won't get too attached to that
code though... :-)

--- Keith



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


[notmuch] [PATCH 6/9] Reply to individual messages using message library

2009-11-27 Thread Keith Amidon
{-- Fri, 27 Nov 2009 20:48:46 +0530: Aneesh  wrote: --}

  Aneesh> Hi, Really good set of patches. I am right now testing with
  Aneesh> the set of changes and found that

Thanks!

  Aneesh> a) notmuch-show-reply-current and other helpers doesn't put
  Aneesh> the mail content i am replying in the reply buffer in quoted
  Aneesh> form. What i was expecting was something similar to
  Aneesh> notmuch-show-reply but one that doesn't add all the email
  Aneesh> address.

Well, the fact that I mainly cared about message forwarding and not the
reply functions is turning out to show rather badly...  There appear to
be a number of problems with the reply functions starting with the fact
that I kill the buffer that has the original message contents in it as
soon as the reply buffer is constructed, which message doesn't really
like.  I can think of some ways around the problems but I'm getting the
sense that enhancing the notmuch C program's ability to generate
different styles of replies would be preferred to what I have done.

Forwarding works fine though... :-)

  Aneesh> b) The key-binding MA is really difficult to type. How about
  Aneesh> (kbd "M-a") ?  c) I liked the mail forward feature

My main criteria in selecting key bindings was that they not conflict
with current ones.  If this were to become the preferred way to do this
I'd be happy to change them to whatever consensus emerges.

 --- Keith