Re: Address Completion in Emacs
This thread inspired me to look a little more deeply into the address completion issues I've been having since switching to corfu as well. It was a rather long and twisted journey but I ended up getting completion using corfu working with the following in my init file: ;; Make corfu-based address completion work (defun kea/notmuch-address-message-capf () "Return completion data for email addresses in notmuch-address. Meant for use in `message-completion-alist'." (when (and (bound-and-true-p notmuch-address-completions)) (let ((now (float-time)) (end (save-excursion (skip-chars-forward "^, \t\n") (point))) (start (save-excursion (skip-chars-backward "^, \t\n") (point (when (> (- now notmuch-address-last-harvest) 86400) ;; Synchronously get completions now and update addresses in ;; background. Handles startup case where there might not be ;; anything in notmuch-address-completions because ;; notmuch-address-last-harvest will be 0. (notmuch-address-harvest (buffer-substring-no-properties start end) t) (notmuch-address-harvest-trigger)) `(,start ,end ,notmuch-address-completions 'mail (defun kea/setup-notmuch-message-mode () (setq notmuch-address-use-company nil) (setq message-completion-alist `((,message-newgroups-header-regexp . ,#'message-expand-group) (,message-email-recipient-header-regexp . ,#'kea/notmuch-address-message-capf (add-hook 'notmuch-message-mode-hook #'kea/setup-notmuch-message-mode) Note that I set mail-user-agent to notmuch-user-agent. Cheers! --- Keith ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Multiple header sources for an index.header query prefix?
On 8/15/21 12:27 PM, David Bremner wrote: I should repeat my advertising for the (in-progress) s-expression query parser [1], which would allow defining macros to group various user defined headers. So assuming headers XSpam and XSpamResult are defined, $ notmuch config set squery.Spam '(macro (term) (or (XSpam term) (XSpamResult term)))' $ notmuch search --query=sexp '(Spam "foo bar baz")' If that seems workable for you, you could just wait ;). Neat! I'll check it out. Thanks for the pointer. --- Keith ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Multiple header sources for an index.header query prefix?
On 8/5/21 3:44 AM, David Bremner wrote I started thinking about how I would add this feature and was thinking it might be better to support in the configuration by using semi-colon separated values like some of the other config options. For example: [index] header.Spam=X-Spam;X-Spam-Result Does this seem a reasonable way to go? Is this an extension of the custom header indexing behavior that you would be interested in? It sounds reasonable. Finally, any suggestions for approaching an implementation? In particular, I believe there were some recent changes to also store the configuration in the database. Any thoughts on how this suggestion would interact with that? An implementation would need to update _notmuch_message_index_user_headers to iterate (using notmuch_config_get_values_string) over the desired headers. Basically the call to `_notmuch_message_gen_terms` needs to be repeated once for each header, using the same value for `prefix_name`. And of course the tests and notmuch-search-terms(7) would need to be updated. Thanks for the encouragement and suggestions. The time it has taken me to respond to this thread is a fairly accurate indication of the amount of time I have to work on this right now, but it is something that I'd definitely would find useful so I'll plug away on it when I can make time and update the list when I hopefully get something working. Thanks again, Keith ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Multiple header sources for an index.header query prefix?
I've been a very happy user of notmuch for a very long time. Thank you for such a great tool! Recently I've been working on implementing a new workflow for handling email which uses automated tagging much more heavily. In doing so, I want to use some custom header indexes to construct some of the searches and it seems like it would be very convenient to be able to index multiple custom headers under the same query prefix. For example, I'd like to be able to index both X-spam and X-Spam-Result under the query prefix "Spam:". I tried just adding two custom header lines to the config file with the same query prefix, like: [index] header.Spam=X-Spam header.Spam=X-Spam-Result It appeared that after reindexing, notmuch just used the final line with the same query prefix. In addition, the python bindings config parser fails on such a configuration with an error that the header value is already in use. Checking the code, it this behavior seems consistent. I started thinking about how I would add this feature and was thinking it might be better to support in the configuration by using semi-colon separated values like some of the other config options. For example: [index] header.Spam=X-Spam;X-Spam-Result Does this seem a reasonable way to go? Is this an extension of the custom header indexing behavior that you would be interested in? Finally, any suggestions for approaching an implementation? In particular, I believe there were some recent changes to also store the configuration in the database. Any thoughts on how this suggestion would interact with that? Thanks for your help! Regards, Keith ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: tell me how to do this (mass tagging of messages)
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
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
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
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
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
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
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
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?
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?
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?
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?
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?
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
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
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.
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.
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
{-- 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
{-- 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
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
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
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
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
{-- 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
{-- 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
{-- 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
{-- 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
{-- 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
{-- 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
{-- 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
