Re: [PATCH] emacs: call "notmuch tag" only once when archiving a thread
On Tue, 3 Jan 2012 20:29:06 +0200, Jani Nikula wrote: > Optimize thread archiving by combining all the -inbox tagging operations to > a single "notmuch tag" call. Also skip redisplay of tag changes in current > buffer, as it is immediately killed by the archiving functions. > > For threads in the order of tens or a hundred inbox tagged messages, this > gives a noticeable speedup. > > On the downside, IIRC Xapian does not perform very well if the query (in > this case a lot of message-ids OR'd together) is very big. It is unknown to > me at which point this approach would become slower than the original one > by one tagging approach, if ever. > > Also, this introduces a limitation to the number of messages that can be > archived at the same time (through ARG_MAX limiting the command line). At > least on Linux this seems more like a theoretical limitation than a real > one. IIRC some systems have like 32768 byte command line limit. If the change did tagging in like 100-message batches then this limit is hardly exceeded (if message-id's max 80 characters then command line is 8000+ bytes)... Hmm -- is there a length limit for message-id. If not maybe when appending message id's keep counting length and tag in batches based on that lenght value. Hundreds of messages per tagging operation instead of one is good improvements. > Signed-off-by: Jani Nikula Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Info about notmuch database
Hello! I like notmuch a lot, so I'm writing a (conceptually) similar software about addressbook: it will scan all your emails, storing email addresses in a xapian database (you can think of it as little brother database[1] on steroids) The part that I'd like to re-implement is "notmuch new": it seems that in the xapian db there is not only informations about each mail, but also the mtime of each directory. My impression is this being "chaotic", but probably I am just missing the point. So, here's the question: how is the db "structured"? is there any documentation to look at? [1] http://www.spinnaker.de/lbdb/ -- boyska GPG: 0x520CE393 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] NEWS: consistent 2-space indentation
On Wed, 4 Jan 2012 15:26:52 +0200, Tomi Ollila wrote: > In NEWS file, indentation for item descriptions is generally 2 spaces > but in a few cases there were 3 or 4 (4 caused different markdown > handling) space indentations. Indentation in those lines are brought > to consistent 2-space indentation. > Note that this patch touches spacing in "historical" content -- > content of released versions 0.10.2, 0.10 and 0.6 -- in NEWS file. Hey, Tomi. I don't see that as being a big deal. I also suggest we move to a NEWS directory, with each release getting a separate file named after the release. If we also formated the NEWS entries in proper markdown it would make it trivial to sync the NEWS to the wiki. jamie. pgpRZ7GmyaNUY.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [ANNOUNCE] mutt with notmuch support
On Tue, 3 Jan 2012 20:59:51 +0100, Karel Zak wrote: > > I had to tweak your use of notmuch_database_find_message (I'm using > > 0.11_rc2) but otherwise it compiles fine. > > Unfortunately, the latest package for Fedora is notmuch-0.5-4.fc15 ;-( > > But I'm ready to accept patches to make it compatible with other > distros and the latest upstream. Hey, Karel. I know there are a lot of people out here that are interested in playing with mutt-kz. However, notmuch 0.5 is really old and is unfortunately an API version ago. Until we can get notmuch working with gmime 2.6, and get a much-needed update to the Fedora package, would you mind developing against a compiled-from-source version of notmuch from the latest release? I think you could get a lot of users in short order if mutt-kz could work on systems other than Fedora. jamie. pgpGgsnGFRdOZ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 5/7] py3k: the basestring and unicode types are removed in python 3
On Mon, 02 Jan 2012 16:15:58 +0100, Sebastian Spaeth
wrote:
> Happy new year. Pushed patches 1-4 of this series so far. Looking fine,
> but ugh, the below seems like a rather ugly hack in a function that is
> probably called quite often.
>
> Isn't there a more pretty variant avoiding these sys.version_info checks
> all over the place?
>
> > @@ -200,9 +201,9 @@ def _str(value):
> >
> > C++ code expects strings to be well formatted and
> > unicode strings to have no null bytes."""
> > -if not isinstance(value, basestring):
> > +if not isinstance(value, basestring if sys.version_info[0] == 2 else
> > str):
> > raise TypeError("Expected str or unicode, got %s" %
> > str(type(value)))
> > -if isinstance(value, unicode):
> > +if sys.version_info[0] == 3 or isinstance(value, unicode):
> > return value.encode('UTF-8')
> > return value
Does the Python3StringMixIn stuff in later patches already handle this
patch -- and making this obsolete ?
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [ANNOUNCE] mutt with notmuch support
On Jan 04, 2012 at 10:07 AM -0800, Jameson Graef Rollins wrote: Hey, Karel. I know there are a lot of people out here that are interested in playing with mutt-kz. However, notmuch 0.5 is really old and is unfortunately an API version ago. Until we can get notmuch working with gmime 2.6, and get a much-needed update to the Fedora package, would you mind developing against a compiled-from-source version of notmuch from the latest release? I think you could get a lot of users in short order if mutt-kz could work on systems other than Fedora. Seconded. Also, while mutt might be in maintenance mode, something like this might bump it into active mode if the mutt developer community was involved. pgpaQFQozWisl.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Info about notmuch database
On Wed, 04 Jan 2012 15:49:19 +, boyska wrote: > Hello! > I like notmuch a lot, so I'm writing a (conceptually) similar software > about addressbook: it will scan all your emails, storing email > addresses > in a xapian database (you can think of it as little brother database[1] > on > steroids) > The part that I'd like to re-implement is "notmuch new": it seems that > in the xapian db there is not only informations about each mail, but > also the mtime of each directory. My impression is this being > "chaotic", > but probably I am just missing the point. > > So, here's the question: how is the db "structured"? is there any > documentation to look at? > > [1] http://www.spinnaker.de/lbdb/ > > -- > boyska > GPG: 0x520CE393 There's a description of the DB "schema" in lib/database.cc in the notmuch source code. But you may also consider just using libnotmuch instead, if that's enough for what you want to do. Also: why Xapian? I'm already using something similar I wrote with Python, storing everything in a dictionary, using Pickle to save that to disk: 162 lines of code and 45 kb of data are enough to store my addressbook and have completion in Emacs... Regards, -- Thomas/Schnouki pgpLQ0UslCmY9.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Info about notmuch database
On Thu, Jan 05, 2012 at 04:04:22PM +0100, Thomas Jost wrote: > On Wed, 04 Jan 2012 15:49:19 +, boyska wrote: > > Hello! > > I like notmuch a lot, so I'm writing a (conceptually) similar software > > about addressbook: it will scan all your emails, storing email > > addresses > > in a xapian database (you can think of it as little brother database[1] > > on > > steroids) > > The part that I'd like to re-implement is "notmuch new": it seems that > > in the xapian db there is not only informations about each mail, but > > also the mtime of each directory. My impression is this being > > "chaotic", > > but probably I am just missing the point. > > > > So, here's the question: how is the db "structured"? is there any > > documentation to look at? > > > > [1] http://www.spinnaker.de/lbdb/ > > > > -- > > boyska > > GPG: 0x520CE393 > > There's a description of the DB "schema" in lib/database.cc in the > notmuch source code. But you may also consider just using libnotmuch > instead, if that's enough for what you want to do. thanks, found it, much clearer now. But I really can't understand why not just putting these things on a separate file :) atomic consistency issues? > Also: why Xapian? I'm already using something similar I wrote with > Python, storing everything in a dictionary, using Pickle to save that to > disk: 162 lines of code and 45 kb of data are enough to store my > addressbook and have completion in Emacs... dictionary approach is fine to manage a "manual" addressbook, where you store addresses. But what I want is an _automatic_ addressbook, like the lbdb one, which just indexes all seen emails. The grep approach is better from this point of view, but still not advanced enough for me. For example, I'd like to store "cooccorrences": if some email is used in the same mail of some other, then it must contain a relationship; for example, your email should be correlated to the notmuch mailinglist, because you wrote to it. (they should be 0-weighted xapian term). Also, I want to give more importance to email addresses which are frequently seen, and much less to not-so-frequently seen. Xapian makes these really easy, so the question is "why not using it?" ;) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Info about notmuch database
On Thu, 5 Jan 2012 16:38:07 +0100, boyska wrote: > > There's a description of the DB "schema" in lib/database.cc in the > > notmuch source code. But you may also consider just using libnotmuch > > instead, if that's enough for what you want to do. > > thanks, found it, much clearer now. > But I really can't understand why not just putting these things on a > separate file :) atomic consistency issues? I doubt it's for consistency (see commit 824dad76), more likely it's because people should use libnotmuch rather than directly hacking into the DB ;) > > Also: why Xapian? I'm already using something similar I wrote with > > Python, storing everything in a dictionary, using Pickle to save that to > > disk: 162 lines of code and 45 kb of data are enough to store my > > addressbook and have completion in Emacs... > > dictionary approach is fine to manage a "manual" addressbook, where you > store addresses. But what I want is an _automatic_ addressbook, like the > lbdb one, which just indexes all seen emails. That's what my little script does too: index emails and how many times they appear in the DB so that completion shows more frequently used ones first. The indexing is done after running "notmuch new", when running my auto-tagging script. I'm too lazy to maintain a "manual" addressbook correctly :) > The grep approach is better from this point of view, but still not > advanced enough for me. > For example, I'd like to store "cooccorrences": if some email is used in > the same mail of some other, then it must contain a relationship; for > example, your email should be correlated to the notmuch mailinglist, > because you wrote to it. (they should be 0-weighted xapian term). Also, > I want to give more importance to email addresses which are frequently > seen, and much less to not-so-frequently seen. Xapian makes these really > easy, so the question is "why not using it?" ;) Nice ideas, and Xapian is probably a good choice for doing that kind of stuff :) Do you plan to use this addressbook with notmuch-address.el, or will it be a standalone program? Regards, -- Thomas/Schnouki pgpMf0rrQZ1l2.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: call "notmuch tag" only once when archiving a thread
On Tue, 3 Jan 2012 20:29:06 +0200, Jani Nikula wrote: > Optimize thread archiving by combining all the -inbox tagging operations to > a single "notmuch tag" call. Perhaps I’m missing something, but is there anything preventing emacs from just doing the following? notmuch tag -inbox thread:000whatever -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 0/4] notmuch reply bugfix & reply to sender only
Hi all - Patch 1 is a bugfix worth considering for release branch independently. Included in the same patchset as the following ones depend on it. The rest of the patches add reply-to-sender (as opposed to reply-to-all) functionality to "notmuch reply" and emacs. Bikeshedding topic #1: How about making replying to just the sender the default in "notmuch reply", and having --reply-all option (instead of --no-reply-all)? Bikeshedding topic #2: How about binding 'r' to reply to just the sender by default, and making 'R' reply-all (instead of vice versa)? Obviously, this set is missing tests and documentation, but I'd like to get the first round of review and the above topics settled first. :) BR, Jani. Jani Nikula (4): cli: fix use of uninitialized variable in "notmuch reply" cli: convert "notmuch reply" to use the new argument parser cli: add support for replying just to the sender in "notmuch reply" emacs: add support for replying just to the sender of messages and threads emacs/notmuch-mua.el |8 ++- emacs/notmuch-show.el | 12 - emacs/notmuch.el | 11 - notmuch-reply.c | 129 ++-- 4 files changed, 93 insertions(+), 67 deletions(-) -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/4] cli: fix use of uninitialized variable in "notmuch reply"
notmuch_show_params_t params is only initialized partially in
notmuch_reply_command(). The only field that is used uninitialized is
params.decrypt. It is usually non-zero, making "notmuch reply" on encrypted
messages work by coincidence.
Initialize params properly, and set params.decrypt as needed.
Signed-off-by: Jani Nikula
---
notmuch-reply.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index f8d5f64..1f33a86 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -621,11 +621,9 @@ notmuch_reply_command (void *ctx, int argc, char *argv[])
char *opt, *query_string;
int i, ret = 0;
int (*reply_format_func)(void *ctx, notmuch_config_t *config,
notmuch_query_t *query, notmuch_show_params_t *params);
-notmuch_show_params_t params;
+notmuch_show_params_t params = { .part = -1 };
reply_format_func = notmuch_reply_format_default;
-params.part = -1;
-params.cryptoctx = NULL;
argc--; argv++; /* skip subcommand argument */
@@ -647,10 +645,12 @@ notmuch_reply_command (void *ctx, int argc, char *argv[])
} else if ((STRNCMP_LITERAL (argv[i], "--decrypt") == 0)) {
if (params.cryptoctx == NULL) {
GMimeSession* session = g_object_new(g_mime_session_get_type(),
NULL);
- if (NULL == (params.cryptoctx = g_mime_gpg_context_new(session,
"gpg")))
+ if (NULL == (params.cryptoctx = g_mime_gpg_context_new(session,
"gpg"))) {
fprintf (stderr, "Failed to construct gpg context.\n");
- else
+ } else {
+ params.decrypt = TRUE;
g_mime_gpg_context_set_always_trust((GMimeGpgContext*)params.cryptoctx, FALSE);
+ }
g_object_unref (session);
session = NULL;
}
--
1.7.5.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/4] cli: convert "notmuch reply" to use the new argument parser
Use the new notmuch argument parser to handle arguments in "notmuch
reply". There should be no functional changes.
Signed-off-by: Jani Nikula
---
notmuch-reply.c | 75 +++
1 files changed, 37 insertions(+), 38 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 1f33a86..000f6da 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -612,62 +612,61 @@ notmuch_reply_format_headers_only(void *ctx,
return 0;
}
+enum {
+FORMAT_DEFAULT,
+FORMAT_HEADERS_ONLY,
+};
+
int
notmuch_reply_command (void *ctx, int argc, char *argv[])
{
notmuch_config_t *config;
notmuch_database_t *notmuch;
notmuch_query_t *query;
-char *opt, *query_string;
-int i, ret = 0;
+char *query_string;
+int opt_index, ret = 0;
int (*reply_format_func)(void *ctx, notmuch_config_t *config,
notmuch_query_t *query, notmuch_show_params_t *params);
notmuch_show_params_t params = { .part = -1 };
+int format = FORMAT_DEFAULT;
+notmuch_bool_t decrypt = FALSE;
+
+notmuch_opt_desc_t options[] = {
+ { NOTMUCH_OPT_KEYWORD, &format, "format", 'f',
+ (notmuch_keyword_t []){ { "default", FORMAT_DEFAULT },
+ { "headers-only", FORMAT_HEADERS_ONLY },
+ { 0, 0 } } },
+ { NOTMUCH_OPT_BOOLEAN, &decrypt, "decrypt", 'd', 0 },
+ { 0, 0, 0, 0, 0 }
+};
-reply_format_func = notmuch_reply_format_default;
-
-argc--; argv++; /* skip subcommand argument */
+opt_index = parse_arguments (argc, argv, options, 1);
+if (opt_index < 0) {
+ /* diagnostics already printed */
+ return 1;
+}
-for (i = 0; i < argc && argv[i][0] == '-'; i++) {
- if (strcmp (argv[i], "--") == 0) {
- i++;
- break;
- }
-if (STRNCMP_LITERAL (argv[i], "--format=") == 0) {
- opt = argv[i] + sizeof ("--format=") - 1;
- if (strcmp (opt, "default") == 0) {
- reply_format_func = notmuch_reply_format_default;
- } else if (strcmp (opt, "headers-only") == 0) {
- reply_format_func = notmuch_reply_format_headers_only;
- } else {
- fprintf (stderr, "Invalid value for --format: %s\n", opt);
- return 1;
- }
- } else if ((STRNCMP_LITERAL (argv[i], "--decrypt") == 0)) {
- if (params.cryptoctx == NULL) {
- GMimeSession* session = g_object_new(g_mime_session_get_type(),
NULL);
- if (NULL == (params.cryptoctx = g_mime_gpg_context_new(session,
"gpg"))) {
- fprintf (stderr, "Failed to construct gpg context.\n");
- } else {
- params.decrypt = TRUE;
-
g_mime_gpg_context_set_always_trust((GMimeGpgContext*)params.cryptoctx, FALSE);
- }
- g_object_unref (session);
- session = NULL;
- }
+if (format == FORMAT_HEADERS_ONLY)
+ reply_format_func = notmuch_reply_format_headers_only;
+else
+ reply_format_func = notmuch_reply_format_default;
+
+if (decrypt) {
+ GMimeSession* session = g_object_new (g_mime_session_get_type(), NULL);
+ params.cryptoctx = g_mime_gpg_context_new (session, "gpg");
+ if (params.cryptoctx) {
+ g_mime_gpg_context_set_always_trust ((GMimeGpgContext*)
params.cryptoctx, FALSE);
+ params.decrypt = TRUE;
} else {
- fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
- return 1;
+ fprintf (stderr, "Failed to construct gpg context.\n");
}
+ g_object_unref (session);
}
-argc -= i;
-argv += i;
-
config = notmuch_config_open (ctx, NULL, NULL);
if (config == NULL)
return 1;
-query_string = query_string_from_args (ctx, argc, argv);
+query_string = query_string_from_args (ctx, argc-opt_index,
argv+opt_index);
if (query_string == NULL) {
fprintf (stderr, "Out of memory\n");
return 1;
--
1.7.5.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 3/4] cli: add support for replying just to the sender in "notmuch reply"
Add new option --no-reply-all to "notmuch reply" to reply just to the
sender instead of sender and all recipients.
Signed-off-by: Jani Nikula
---
notmuch-reply.c | 52
1 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 000f6da..57458ec 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -170,7 +170,7 @@ address_is_users (const char *address, notmuch_config_t
*config)
/* For each address in 'list' that is not configured as one of the
* user's addresses in 'config', add that address to 'message' as an
- * address of 'type'.
+ * address of 'type', if 'add' is true.
*
* The first address encountered that *is* the user's address will be
* returned, (otherwise NULL is returned).
@@ -179,7 +179,8 @@ static const char *
add_recipients_for_address_list (GMimeMessage *message,
notmuch_config_t *config,
GMimeRecipientType type,
-InternetAddressList *list)
+InternetAddressList *list,
+notmuch_bool_t add)
{
InternetAddress *address;
int i;
@@ -197,7 +198,7 @@ add_recipients_for_address_list (GMimeMessage *message,
continue;
add_recipients_for_address_list (message, config,
-type, group_list);
+type, group_list, add);
} else {
InternetAddressMailbox *mailbox;
const char *name;
@@ -211,7 +212,7 @@ add_recipients_for_address_list (GMimeMessage *message,
if (address_is_users (addr, config)) {
if (ret == NULL)
ret = addr;
- } else {
+ } else if (add) {
g_mime_message_add_recipient (message, type, name, addr);
}
}
@@ -222,7 +223,7 @@ add_recipients_for_address_list (GMimeMessage *message,
/* For each address in 'recipients' that is not configured as one of
* the user's addresses in 'config', add that address to 'message' as
- * an address of 'type'.
+ * an address of 'type', if 'add' is true.
*
* The first address encountered that *is* the user's address will be
* returned, (otherwise NULL is returned).
@@ -231,7 +232,8 @@ static const char *
add_recipients_for_string (GMimeMessage *message,
notmuch_config_t *config,
GMimeRecipientType type,
- const char *recipients)
+ const char *recipients,
+ notmuch_bool_t add)
{
InternetAddressList *list;
@@ -242,7 +244,7 @@ add_recipients_for_string (GMimeMessage *message,
if (list == NULL)
return NULL;
-return add_recipients_for_address_list (message, config, type, list);
+return add_recipients_for_address_list (message, config, type, list, add);
}
/* Does the address in the Reply-To header of 'message' already appear
@@ -284,7 +286,9 @@ reply_to_header_is_redundant (notmuch_message_t *message)
return 0;
}
-/* Augments the recipients of reply from the headers of message.
+/* Augments the recipients of reply from the headers of message. If 'reply_all'
+ * is true, use sender and all recipients, otherwise use just the sender
+ * ("reply-to" or "from" headers).
*
* If any of the user's addresses were found in these headers, the first
* of these returned, otherwise NULL is returned.
@@ -292,17 +296,19 @@ reply_to_header_is_redundant (notmuch_message_t *message)
static const char *
add_recipients_from_message (GMimeMessage *reply,
notmuch_config_t *config,
-notmuch_message_t *message)
+notmuch_message_t *message,
+notmuch_bool_t reply_all)
{
struct {
const char *header;
const char *fallback;
GMimeRecipientType recipient_type;
+ notmuch_bool_t always; /* use entry when not reply_all */
} reply_to_map[] = {
- { "reply-to", "from", GMIME_RECIPIENT_TYPE_TO },
- { "to", NULL, GMIME_RECIPIENT_TYPE_TO },
- { "cc", NULL, GMIME_RECIPIENT_TYPE_CC },
- { "bcc",NULL, GMIME_RECIPIENT_TYPE_BCC }
+ { "reply-to", "from", GMIME_RECIPIENT_TYPE_TO, TRUE },
+ { "to", NULL, GMIME_RECIPIENT_TYPE_TO, FALSE },
+ { "cc", NULL, GMIME_RECIPIENT_TYPE_CC, FALSE },
+ { "bcc",NULL, GMIME_RECIPIENT_TYPE_BCC, FALSE }
};
const char *from_addr = NULL;
unsigned int i;
@@ -334,7 +340,8 @@ add_recipients_from_message (GMimeMessage *reply,
addr = add_recipients_for_string (reply, config,
reply_to_map[i].recipient_type,
- recipients);
+
[PATCH 4/4] emacs: add support for replying just to the sender of messages and threads
Make the search and show reply functions reply just to the sender, and
provide reply-all counterparts to reply to all. Add key binding 'R' to
reply to sender, while keeping 'r' as reply-to-all, both in search and show
views.
Signed-off-by: Jani Nikula
---
emacs/notmuch-mua.el |8 +---
emacs/notmuch-show.el | 12 +---
emacs/notmuch.el | 11 +--
3 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 7114e48..3cdf360 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -71,12 +71,14 @@ list."
(push header message-hidden-headers)))
notmuch-mua-hidden-headers))
-(defun notmuch-mua-reply (query-string &optional sender)
+(defun notmuch-mua-reply (query-string &optional reply-all sender)
(let (headers
body
(args '("reply")))
(if notmuch-show-process-crypto
(setq args (append args '("--decrypt"
+(unless reply-all
+ (setq args (append args '("--no-reply-all"
(setq args (append args (list query-string)))
;; This make assumptions about the output of `notmuch reply', but
;; really only that the headers come first followed by a blank
@@ -217,13 +219,13 @@ the From: address first."
(notmuch-mua-forward-message))
(notmuch-mua-forward-message)))
-(defun notmuch-mua-new-reply (query-string &optional prompt-for-sender)
+(defun notmuch-mua-new-reply (query-string &optional reply-all
prompt-for-sender)
"Invoke the notmuch reply window."
(interactive "P")
(let ((sender
(when prompt-for-sender
(notmuch-mua-prompt-for-sender
-(notmuch-mua-reply query-string sender)))
+(notmuch-mua-reply query-string reply-all sender)))
(defun notmuch-mua-send-and-exit (&optional arg)
(interactive "P")
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 5502efd..6f812d8 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -932,7 +932,8 @@ thread id. If a prefix is given, crypto processing is
toggled."
(define-key map "s" 'notmuch-search)
(define-key map "m" 'notmuch-mua-new-mail)
(define-key map "f" 'notmuch-show-forward-message)
- (define-key map "r" 'notmuch-show-reply)
+ (define-key map "r" 'notmuch-show-reply-all)
+ (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 "V" 'notmuch-show-view-raw-message)
@@ -1237,9 +1238,14 @@ any effects from previous calls to
(notmuch-show-previous-message)
(defun notmuch-show-reply (&optional prompt-for-sender)
- "Reply to the current message."
+ "Reply to the sender of the current message."
(interactive "P")
- (notmuch-mua-new-reply (notmuch-show-get-message-id) prompt-for-sender))
+ (notmuch-mua-new-reply (notmuch-show-get-message-id) nil prompt-for-sender))
+
+(defun notmuch-show-reply-all (&optional prompt-for-sender)
+ "Reply to the sender and all recipients of the current message."
+ (interactive "P")
+ (notmuch-mua-new-reply (notmuch-show-get-message-id) t prompt-for-sender))
(defun notmuch-show-forward-message (&optional prompt-for-sender)
"Forward the current message."
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index fde2377..bd1fd4f 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -206,7 +206,8 @@ For a mouse binding, return nil."
(define-key map ">" 'notmuch-search-last-thread)
(define-key map "p" 'notmuch-search-previous-thread)
(define-key map "n" 'notmuch-search-next-thread)
-(define-key map "r" 'notmuch-search-reply-to-thread)
+(define-key map "r" 'notmuch-search-reply-all-to-thread)
+(define-key map "R" 'notmuch-search-reply-to-thread)
(define-key map "m" 'notmuch-mua-new-mail)
(define-key map "s" 'notmuch-search)
(define-key map "o" 'notmuch-search-toggle-order)
@@ -444,7 +445,13 @@ Complete list of currently available key bindings:
"Begin composing a reply to the entire current thread in a new buffer."
(interactive "P")
(let ((message-id (notmuch-search-find-thread-id)))
-(notmuch-mua-new-reply message-id prompt-for-sender)))
+(notmuch-mua-new-reply message-id nil prompt-for-sender)))
+
+(defun notmuch-search-reply-all-to-thread (&optional prompt-for-sender)
+ "Begin composing a reply-all to the entire current thread in a new buffer."
+ (interactive "P")
+ (let ((message-id (notmuch-search-find-thread-id)))
+(notmuch-mua-new-reply message-id t prompt-for-sender)))
(defun notmuch-call-notmuch-process (&rest args)
"Synchronously invoke \"notmuch\" with the given list of arguments.
--
1.7.5.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: call "notmuch tag" only once when archiving a thread
On Thu, 05 Jan 2012 15:10:33 -0500, Aaron Ecay wrote: > On Tue, 3 Jan 2012 20:29:06 +0200, Jani Nikula wrote: > > Optimize thread archiving by combining all the -inbox tagging operations to > > a single "notmuch tag" call. > > Perhaps I’m missing something, but is there anything preventing emacs > from just doing the following? > > notmuch tag -inbox thread:000whatever In the search view it does exactly this. In the show view it only modifies the messages that are currently visible. This is to make sure you don't accidentally archive things that have arrived after refreshing the buffer. I think this is safest. I suppose the point in the difference is that in search view you're archiving the thread without seeing the messages anyway. In show view you have had enough interest in the thread to open it, and you're making the decision based on the messages you've seen. BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/4] notmuch reply bugfix & reply to sender only
On Thu, 5 Jan 2012 22:25:11 +0200, Jani Nikula wrote: > Bikeshedding topic #1: How about making replying to just the sender the > default > in "notmuch reply", and having --reply-all option (instead of --no-reply-all)? > > Bikeshedding topic #2: How about binding 'r' to reply to just the sender by > default, and making 'R' reply-all (instead of vice versa)? I personally like both of these suggestions, and would not be bothered by the changed default, so I support both of these changes. Maybe we could just use '--all', instead of '--reply-all'? The 'reply' part seems kind of redundant with the command: notmuch reply --all vs. notmuch reply --reply-all jamie. pgpZ32BooFMAl.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: call "notmuch tag" only once when archiving a thread
On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote: > In the search view it does exactly this. I worry about race conditions in this case, though. I frequently archive threads after I've read everything, but I still want to know if new message to that thread come in. If I attempt to archive a thread in notmuch-search, but a new message has entered the thread without me knowing it, I'll archive the new message before I had a chance to look at it. jamie. pgpzcJ999EhXi.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: call "notmuch tag" only once when archiving a thread
On Thu, 05 Jan 2012 12:38:18 -0800, Jameson Graef Rollins wrote: > On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote: > > In the search view it does exactly this. > > I worry about race conditions in this case, though. I frequently > archive threads after I've read everything, but I still want to know if > new message to that thread come in. If I attempt to archive a thread in > notmuch-search, but a new message has entered the thread without me > knowing it, I'll archive the new message before I had a chance to look > at it. Just to be clear: The patch in question does not alter this behaviour. The race you describe is there already. And at a glance, it does not look like something that would be trivial to fix. The buffer does not have the information to do that. BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/4] notmuch reply bugfix & reply to sender only
Hello > Bikeshedding topic #1: How about making replying to just the sender the > default > in "notmuch reply", and having --reply-all option (instead of --no-reply-all)? In id:"87pqn5cg4g@yoom.home.cworth.org" cworth suggested using --reply-to=sender vs. --reply-to=all (keeping the latter the default). (This was in response to a patch set I submitted implementing a reply-to-sender option (*)) > Bikeshedding topic #2: How about binding 'r' to reply to just the sender by > default, and making 'R' reply-all (instead of vice versa)? Personally I would prefer this but it is easy to customise. However, one more significant choice is what to do on reply-to-sender to an email from the user himself. My patch used the following logic: look at the reply-to, from , to, cc lines until you find a non-user address and use that line for the reply. My recollection is that this is roughly what mutt does. At least for the common "from user" cases mutt does reply-to-one : just to to: person group-reply: to to: and cc: people Best wishes Mark (*) I have a version of that patch-set which applies to master if that would be useful to anyone, and I recently started writing tests in preparation for re-submitting. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Update NEWS for Emacs changes
On Wed, 4 Jan 2012 10:25:07 +0100, Thomas Jost wrote: > --- > Hello world, > > Here's my part. (Also describes Ivy Foster's patch for > notmuch-hello-mode-hook.) > Pushed to release; some mashing needed to fit with Jamie's changes. Have look and see if anything got too mashed. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: fix notmuch-show-indent-messages-width customization variable name
On Mon, 2 Jan 2012 14:23:02 -0800, Jameson Graef Rollins wrote: > The name was originally notmuch-indent-messages-width, which is > inconsistent with our variable naming convention. > --- > Sorry, I forgot to fix the tests in the original patch. Finally pushed both, with a couple of typo fixes. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/4] notmuch reply bugfix & reply to sender only
On Thu, Jan 5, 2012 at 13:25, Jani Nikula wrote: > Bikeshedding topic #1: How about making replying to just the sender the > default > in "notmuch reply", and having --reply-all option (instead of --no-reply-all)? > > Bikeshedding topic #2: How about binding 'r' to reply to just the sender by > default, and making 'R' reply-all (instead of vice versa)? I like both these suggestions. This would bring the notmuch behavior in line with gmail, which is what I tend to expect. Mark Walters brings up a good point, that there is a question of what to do when the user tries to reply to their own email. When I do this, what I intend is to send another email to the last person I emailed in the thread, so I think the suggested heuristic of looking at other headers would work. But, maybe others have a different expectation in this case? ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Exporting mime email
Hello What is the best way of exporting/saving as text a mime-encoded email from the emacs interface (e.g, if I want to save a mime-encoded email containing a patch)? For non-mime emails View-raw is fine, but with mime encoded emails such as (picked pretty much at random) id:"1325240897-27525-1-git-send-email-...@dme.org" I haven't found any non-hack method. Many thanks Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Exporting mime email
On Fri, 06 Jan 2012 00:29:39 +, Mark Walters wrote: > What is the best way of exporting/saving as text a mime-encoded email > from the emacs interface (e.g, if I want to save a mime-encoded > email containing a patch)? Maybe you're looking for '|'? That will pipe the raw message to whatever command is specified. jamie. pgpHiVlg4HbsC.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Exporting mime email
Hi On Thu, 05 Jan 2012 16:44:10 -0800, Jameson Graef Rollins wrote: > On Fri, 06 Jan 2012 00:29:39 +, Mark Walters > wrote: > > What is the best way of exporting/saving as text a mime-encoded email > > from the emacs interface (e.g, if I want to save a mime-encoded > > email containing a patch)? > > Maybe you're looking for '|'? That will pipe the raw message to > whatever command is specified. What I would like is a way of exporting the decoded text rather than the raw message. As an explicit example I would like to be able to export a mime encoded email containing a patch, and then do something like patch -p1 < exported_file Sorry for not making myself clear Many thanks Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] cli: fix use of uninitialized variable in "notmuch reply"
On Thu, 5 Jan 2012 22:25:12 +0200, Jani Nikula wrote:
> -notmuch_show_params_t params;
> +notmuch_show_params_t params = { .part = -1 };
>
> reply_format_func = notmuch_reply_format_default;
> -params.part = -1;
Do I understand correctly that this is just a style change, or do you
rely on some c99(?) behaviour of initializing the other elements to 0?
d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Helpers for notmuch developers.
On Wed, 4 Jan 2012 14:01:18 +, David Edmondson wrote: > --- > > I've been using this for a few days and decided to share it to get > feedback. Reviewing patches can be tedious, so I tried to make things > a little simpler. > I didn't have a very thorough look at the code, but I like the functionality. Especially hitting q a few times from magit and being in the right place to reply. > General management (i.e. keeping up to date) of the repository it uses > is your responsibility, as is cleaning out old branches. You can, of > course, just delete the temporary repository after using it - the code > will re-create it next time. maybe the branches could be under some namespace that makes this easy? > +(defvar notmuch-dev-temporary-repository-name (concat "notmuch-dev-" > (user-login-name)) > + "The name of the temporary repository.") Do we care about security at all in this context? I'm always a bit nervous about creating predictably named files/directories in publicly writable places. > + ;; Causes us to switch to the magit buffer - is that unfortunate in > + ;; some situations? > + (magit-status notmuch-dev-temporary-repository-path)) I found it to be a pleasant surprise. > + (shell-command > + (concat > + notmuch-command " show --format=mbox " (shell-quote-argument > search-terms) > + " | " > + "git am --quiet")) > + Hmm. A knee jerk reaction is not to like this, like seeing system in C code. But I don't have a better solution off hand. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[ANNOUNCE] mutt with notmuch support
On Jan 04, 2012 at 10:07 AM -0800, Jameson Graef Rollins wrote: >Hey, Karel. I know there are a lot of people out here that are >interested in playing with mutt-kz. However, notmuch 0.5 is really old >and is unfortunately an API version ago. Until we can get notmuch >working with gmime 2.6, and get a much-needed update to the Fedora >package, would you mind developing against a compiled-from-source >version of notmuch from the latest release? I think you could get a lot >of users in short order if mutt-kz could work on systems other than >Fedora. Seconded. Also, while mutt might be in maintenance mode, something like this might bump it into active mode if the mutt developer community was involved. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 881 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120105/8d9df0f3/attachment.pgp>
Info about notmuch database
On Wed, 04 Jan 2012 15:49:19 +, boyska wrote: > Hello! > I like notmuch a lot, so I'm writing a (conceptually) similar software > about addressbook: it will scan all your emails, storing email > addresses > in a xapian database (you can think of it as little brother database[1] > on > steroids) > The part that I'd like to re-implement is "notmuch new": it seems that > in the xapian db there is not only informations about each mail, but > also the mtime of each directory. My impression is this being > "chaotic", > but probably I am just missing the point. > > So, here's the question: how is the db "structured"? is there any > documentation to look at? > > [1] http://www.spinnaker.de/lbdb/ > > -- > boyska > GPG: 0x520CE393 There's a description of the DB "schema" in lib/database.cc in the notmuch source code. But you may also consider just using libnotmuch instead, if that's enough for what you want to do. Also: why Xapian? I'm already using something similar I wrote with Python, storing everything in a dictionary, using Pickle to save that to disk: 162 lines of code and 45 kb of data are enough to store my addressbook and have completion in Emacs... Regards, -- Thomas/Schnouki -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120105/8ad2890b/attachment-0001.pgp>
Info about notmuch database
On Thu, Jan 05, 2012 at 04:04:22PM +0100, Thomas Jost wrote: > On Wed, 04 Jan 2012 15:49:19 +, boyska > wrote: > > Hello! > > I like notmuch a lot, so I'm writing a (conceptually) similar software > > about addressbook: it will scan all your emails, storing email > > addresses > > in a xapian database (you can think of it as little brother database[1] > > on > > steroids) > > The part that I'd like to re-implement is "notmuch new": it seems that > > in the xapian db there is not only informations about each mail, but > > also the mtime of each directory. My impression is this being > > "chaotic", > > but probably I am just missing the point. > > > > So, here's the question: how is the db "structured"? is there any > > documentation to look at? > > > > [1] http://www.spinnaker.de/lbdb/ > > > > -- > > boyska > > GPG: 0x520CE393 > > There's a description of the DB "schema" in lib/database.cc in the > notmuch source code. But you may also consider just using libnotmuch > instead, if that's enough for what you want to do. thanks, found it, much clearer now. But I really can't understand why not just putting these things on a separate file :) atomic consistency issues? > Also: why Xapian? I'm already using something similar I wrote with > Python, storing everything in a dictionary, using Pickle to save that to > disk: 162 lines of code and 45 kb of data are enough to store my > addressbook and have completion in Emacs... dictionary approach is fine to manage a "manual" addressbook, where you store addresses. But what I want is an _automatic_ addressbook, like the lbdb one, which just indexes all seen emails. The grep approach is better from this point of view, but still not advanced enough for me. For example, I'd like to store "cooccorrences": if some email is used in the same mail of some other, then it must contain a relationship; for example, your email should be correlated to the notmuch mailinglist, because you wrote to it. (they should be 0-weighted xapian term). Also, I want to give more importance to email addresses which are frequently seen, and much less to not-so-frequently seen. Xapian makes these really easy, so the question is "why not using it?" ;)
Info about notmuch database
On Thu, 5 Jan 2012 16:38:07 +0100, boyska wrote: > > There's a description of the DB "schema" in lib/database.cc in the > > notmuch source code. But you may also consider just using libnotmuch > > instead, if that's enough for what you want to do. > > thanks, found it, much clearer now. > But I really can't understand why not just putting these things on a > separate file :) atomic consistency issues? I doubt it's for consistency (see commit 824dad76), more likely it's because people should use libnotmuch rather than directly hacking into the DB ;) > > Also: why Xapian? I'm already using something similar I wrote with > > Python, storing everything in a dictionary, using Pickle to save that to > > disk: 162 lines of code and 45 kb of data are enough to store my > > addressbook and have completion in Emacs... > > dictionary approach is fine to manage a "manual" addressbook, where you > store addresses. But what I want is an _automatic_ addressbook, like the > lbdb one, which just indexes all seen emails. That's what my little script does too: index emails and how many times they appear in the DB so that completion shows more frequently used ones first. The indexing is done after running "notmuch new", when running my auto-tagging script. I'm too lazy to maintain a "manual" addressbook correctly :) > The grep approach is better from this point of view, but still not > advanced enough for me. > For example, I'd like to store "cooccorrences": if some email is used in > the same mail of some other, then it must contain a relationship; for > example, your email should be correlated to the notmuch mailinglist, > because you wrote to it. (they should be 0-weighted xapian term). Also, > I want to give more importance to email addresses which are frequently > seen, and much less to not-so-frequently seen. Xapian makes these really > easy, so the question is "why not using it?" ;) Nice ideas, and Xapian is probably a good choice for doing that kind of stuff :) Do you plan to use this addressbook with notmuch-address.el, or will it be a standalone program? Regards, -- Thomas/Schnouki -- next part ------ A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120105/3e931a97/attachment.pgp>
[PATCH] emacs: call "notmuch tag" only once when archiving a thread
On Tue, 3 Jan 2012 20:29:06 +0200, Jani Nikula wrote: > Optimize thread archiving by combining all the -inbox tagging operations to > a single "notmuch tag" call. Perhaps I?m missing something, but is there anything preventing emacs from just doing the following? notmuch tag -inbox thread:000whatever -- Aaron Ecay
[PATCH 0/4] notmuch reply bugfix & reply to sender only
Hi all - Patch 1 is a bugfix worth considering for release branch independently. Included in the same patchset as the following ones depend on it. The rest of the patches add reply-to-sender (as opposed to reply-to-all) functionality to "notmuch reply" and emacs. Bikeshedding topic #1: How about making replying to just the sender the default in "notmuch reply", and having --reply-all option (instead of --no-reply-all)? Bikeshedding topic #2: How about binding 'r' to reply to just the sender by default, and making 'R' reply-all (instead of vice versa)? Obviously, this set is missing tests and documentation, but I'd like to get the first round of review and the above topics settled first. :) BR, Jani. Jani Nikula (4): cli: fix use of uninitialized variable in "notmuch reply" cli: convert "notmuch reply" to use the new argument parser cli: add support for replying just to the sender in "notmuch reply" emacs: add support for replying just to the sender of messages and threads emacs/notmuch-mua.el |8 ++- emacs/notmuch-show.el | 12 - emacs/notmuch.el | 11 - notmuch-reply.c | 129 ++-- 4 files changed, 93 insertions(+), 67 deletions(-) -- 1.7.5.4
[PATCH 1/4] cli: fix use of uninitialized variable in "notmuch reply"
notmuch_show_params_t params is only initialized partially in
notmuch_reply_command(). The only field that is used uninitialized is
params.decrypt. It is usually non-zero, making "notmuch reply" on encrypted
messages work by coincidence.
Initialize params properly, and set params.decrypt as needed.
Signed-off-by: Jani Nikula
---
notmuch-reply.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index f8d5f64..1f33a86 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -621,11 +621,9 @@ notmuch_reply_command (void *ctx, int argc, char *argv[])
char *opt, *query_string;
int i, ret = 0;
int (*reply_format_func)(void *ctx, notmuch_config_t *config,
notmuch_query_t *query, notmuch_show_params_t *params);
-notmuch_show_params_t params;
+notmuch_show_params_t params = { .part = -1 };
reply_format_func = notmuch_reply_format_default;
-params.part = -1;
-params.cryptoctx = NULL;
argc--; argv++; /* skip subcommand argument */
@@ -647,10 +645,12 @@ notmuch_reply_command (void *ctx, int argc, char *argv[])
} else if ((STRNCMP_LITERAL (argv[i], "--decrypt") == 0)) {
if (params.cryptoctx == NULL) {
GMimeSession* session = g_object_new(g_mime_session_get_type(),
NULL);
- if (NULL == (params.cryptoctx = g_mime_gpg_context_new(session,
"gpg")))
+ if (NULL == (params.cryptoctx = g_mime_gpg_context_new(session,
"gpg"))) {
fprintf (stderr, "Failed to construct gpg context.\n");
- else
+ } else {
+ params.decrypt = TRUE;
g_mime_gpg_context_set_always_trust((GMimeGpgContext*)params.cryptoctx, FALSE);
+ }
g_object_unref (session);
session = NULL;
}
--
1.7.5.4
[PATCH 2/4] cli: convert "notmuch reply" to use the new argument parser
Use the new notmuch argument parser to handle arguments in "notmuch
reply". There should be no functional changes.
Signed-off-by: Jani Nikula
---
notmuch-reply.c | 75 +++
1 files changed, 37 insertions(+), 38 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 1f33a86..000f6da 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -612,62 +612,61 @@ notmuch_reply_format_headers_only(void *ctx,
return 0;
}
+enum {
+FORMAT_DEFAULT,
+FORMAT_HEADERS_ONLY,
+};
+
int
notmuch_reply_command (void *ctx, int argc, char *argv[])
{
notmuch_config_t *config;
notmuch_database_t *notmuch;
notmuch_query_t *query;
-char *opt, *query_string;
-int i, ret = 0;
+char *query_string;
+int opt_index, ret = 0;
int (*reply_format_func)(void *ctx, notmuch_config_t *config,
notmuch_query_t *query, notmuch_show_params_t *params);
notmuch_show_params_t params = { .part = -1 };
+int format = FORMAT_DEFAULT;
+notmuch_bool_t decrypt = FALSE;
+
+notmuch_opt_desc_t options[] = {
+ { NOTMUCH_OPT_KEYWORD, &format, "format", 'f',
+ (notmuch_keyword_t []){ { "default", FORMAT_DEFAULT },
+ { "headers-only", FORMAT_HEADERS_ONLY },
+ { 0, 0 } } },
+ { NOTMUCH_OPT_BOOLEAN, &decrypt, "decrypt", 'd', 0 },
+ { 0, 0, 0, 0, 0 }
+};
-reply_format_func = notmuch_reply_format_default;
-
-argc--; argv++; /* skip subcommand argument */
+opt_index = parse_arguments (argc, argv, options, 1);
+if (opt_index < 0) {
+ /* diagnostics already printed */
+ return 1;
+}
-for (i = 0; i < argc && argv[i][0] == '-'; i++) {
- if (strcmp (argv[i], "--") == 0) {
- i++;
- break;
- }
-if (STRNCMP_LITERAL (argv[i], "--format=") == 0) {
- opt = argv[i] + sizeof ("--format=") - 1;
- if (strcmp (opt, "default") == 0) {
- reply_format_func = notmuch_reply_format_default;
- } else if (strcmp (opt, "headers-only") == 0) {
- reply_format_func = notmuch_reply_format_headers_only;
- } else {
- fprintf (stderr, "Invalid value for --format: %s\n", opt);
- return 1;
- }
- } else if ((STRNCMP_LITERAL (argv[i], "--decrypt") == 0)) {
- if (params.cryptoctx == NULL) {
- GMimeSession* session = g_object_new(g_mime_session_get_type(),
NULL);
- if (NULL == (params.cryptoctx = g_mime_gpg_context_new(session,
"gpg"))) {
- fprintf (stderr, "Failed to construct gpg context.\n");
- } else {
- params.decrypt = TRUE;
-
g_mime_gpg_context_set_always_trust((GMimeGpgContext*)params.cryptoctx, FALSE);
- }
- g_object_unref (session);
- session = NULL;
- }
+if (format == FORMAT_HEADERS_ONLY)
+ reply_format_func = notmuch_reply_format_headers_only;
+else
+ reply_format_func = notmuch_reply_format_default;
+
+if (decrypt) {
+ GMimeSession* session = g_object_new (g_mime_session_get_type(), NULL);
+ params.cryptoctx = g_mime_gpg_context_new (session, "gpg");
+ if (params.cryptoctx) {
+ g_mime_gpg_context_set_always_trust ((GMimeGpgContext*)
params.cryptoctx, FALSE);
+ params.decrypt = TRUE;
} else {
- fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
- return 1;
+ fprintf (stderr, "Failed to construct gpg context.\n");
}
+ g_object_unref (session);
}
-argc -= i;
-argv += i;
-
config = notmuch_config_open (ctx, NULL, NULL);
if (config == NULL)
return 1;
-query_string = query_string_from_args (ctx, argc, argv);
+query_string = query_string_from_args (ctx, argc-opt_index,
argv+opt_index);
if (query_string == NULL) {
fprintf (stderr, "Out of memory\n");
return 1;
--
1.7.5.4
[PATCH 3/4] cli: add support for replying just to the sender in "notmuch reply"
Add new option --no-reply-all to "notmuch reply" to reply just to the
sender instead of sender and all recipients.
Signed-off-by: Jani Nikula
---
notmuch-reply.c | 52
1 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 000f6da..57458ec 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -170,7 +170,7 @@ address_is_users (const char *address, notmuch_config_t
*config)
/* For each address in 'list' that is not configured as one of the
* user's addresses in 'config', add that address to 'message' as an
- * address of 'type'.
+ * address of 'type', if 'add' is true.
*
* The first address encountered that *is* the user's address will be
* returned, (otherwise NULL is returned).
@@ -179,7 +179,8 @@ static const char *
add_recipients_for_address_list (GMimeMessage *message,
notmuch_config_t *config,
GMimeRecipientType type,
-InternetAddressList *list)
+InternetAddressList *list,
+notmuch_bool_t add)
{
InternetAddress *address;
int i;
@@ -197,7 +198,7 @@ add_recipients_for_address_list (GMimeMessage *message,
continue;
add_recipients_for_address_list (message, config,
-type, group_list);
+type, group_list, add);
} else {
InternetAddressMailbox *mailbox;
const char *name;
@@ -211,7 +212,7 @@ add_recipients_for_address_list (GMimeMessage *message,
if (address_is_users (addr, config)) {
if (ret == NULL)
ret = addr;
- } else {
+ } else if (add) {
g_mime_message_add_recipient (message, type, name, addr);
}
}
@@ -222,7 +223,7 @@ add_recipients_for_address_list (GMimeMessage *message,
/* For each address in 'recipients' that is not configured as one of
* the user's addresses in 'config', add that address to 'message' as
- * an address of 'type'.
+ * an address of 'type', if 'add' is true.
*
* The first address encountered that *is* the user's address will be
* returned, (otherwise NULL is returned).
@@ -231,7 +232,8 @@ static const char *
add_recipients_for_string (GMimeMessage *message,
notmuch_config_t *config,
GMimeRecipientType type,
- const char *recipients)
+ const char *recipients,
+ notmuch_bool_t add)
{
InternetAddressList *list;
@@ -242,7 +244,7 @@ add_recipients_for_string (GMimeMessage *message,
if (list == NULL)
return NULL;
-return add_recipients_for_address_list (message, config, type, list);
+return add_recipients_for_address_list (message, config, type, list, add);
}
/* Does the address in the Reply-To header of 'message' already appear
@@ -284,7 +286,9 @@ reply_to_header_is_redundant (notmuch_message_t *message)
return 0;
}
-/* Augments the recipients of reply from the headers of message.
+/* Augments the recipients of reply from the headers of message. If 'reply_all'
+ * is true, use sender and all recipients, otherwise use just the sender
+ * ("reply-to" or "from" headers).
*
* If any of the user's addresses were found in these headers, the first
* of these returned, otherwise NULL is returned.
@@ -292,17 +296,19 @@ reply_to_header_is_redundant (notmuch_message_t *message)
static const char *
add_recipients_from_message (GMimeMessage *reply,
notmuch_config_t *config,
-notmuch_message_t *message)
+notmuch_message_t *message,
+notmuch_bool_t reply_all)
{
struct {
const char *header;
const char *fallback;
GMimeRecipientType recipient_type;
+ notmuch_bool_t always; /* use entry when not reply_all */
} reply_to_map[] = {
- { "reply-to", "from", GMIME_RECIPIENT_TYPE_TO },
- { "to", NULL, GMIME_RECIPIENT_TYPE_TO },
- { "cc", NULL, GMIME_RECIPIENT_TYPE_CC },
- { "bcc",NULL, GMIME_RECIPIENT_TYPE_BCC }
+ { "reply-to", "from", GMIME_RECIPIENT_TYPE_TO, TRUE },
+ { "to", NULL, GMIME_RECIPIENT_TYPE_TO, FALSE },
+ { "cc", NULL, GMIME_RECIPIENT_TYPE_CC, FALSE },
+ { "bcc",NULL, GMIME_RECIPIENT_TYPE_BCC, FALSE }
};
const char *from_addr = NULL;
unsigned int i;
@@ -334,7 +340,8 @@ add_recipients_from_message (GMimeMessage *reply,
addr = add_recipients_for_string (reply, config,
reply_to_map[i].recipient_type,
- recipients);
+
[PATCH 4/4] emacs: add support for replying just to the sender of messages and threads
Make the search and show reply functions reply just to the sender, and
provide reply-all counterparts to reply to all. Add key binding 'R' to
reply to sender, while keeping 'r' as reply-to-all, both in search and show
views.
Signed-off-by: Jani Nikula
---
emacs/notmuch-mua.el |8 +---
emacs/notmuch-show.el | 12 +---
emacs/notmuch.el | 11 +--
3 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 7114e48..3cdf360 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -71,12 +71,14 @@ list."
(push header message-hidden-headers)))
notmuch-mua-hidden-headers))
-(defun notmuch-mua-reply (query-string &optional sender)
+(defun notmuch-mua-reply (query-string &optional reply-all sender)
(let (headers
body
(args '("reply")))
(if notmuch-show-process-crypto
(setq args (append args '("--decrypt"
+(unless reply-all
+ (setq args (append args '("--no-reply-all"
(setq args (append args (list query-string)))
;; This make assumptions about the output of `notmuch reply', but
;; really only that the headers come first followed by a blank
@@ -217,13 +219,13 @@ the From: address first."
(notmuch-mua-forward-message))
(notmuch-mua-forward-message)))
-(defun notmuch-mua-new-reply (query-string &optional prompt-for-sender)
+(defun notmuch-mua-new-reply (query-string &optional reply-all
prompt-for-sender)
"Invoke the notmuch reply window."
(interactive "P")
(let ((sender
(when prompt-for-sender
(notmuch-mua-prompt-for-sender
-(notmuch-mua-reply query-string sender)))
+(notmuch-mua-reply query-string reply-all sender)))
(defun notmuch-mua-send-and-exit (&optional arg)
(interactive "P")
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 5502efd..6f812d8 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -932,7 +932,8 @@ thread id. If a prefix is given, crypto processing is
toggled."
(define-key map "s" 'notmuch-search)
(define-key map "m" 'notmuch-mua-new-mail)
(define-key map "f" 'notmuch-show-forward-message)
- (define-key map "r" 'notmuch-show-reply)
+ (define-key map "r" 'notmuch-show-reply-all)
+ (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 "V" 'notmuch-show-view-raw-message)
@@ -1237,9 +1238,14 @@ any effects from previous calls to
(notmuch-show-previous-message)
(defun notmuch-show-reply (&optional prompt-for-sender)
- "Reply to the current message."
+ "Reply to the sender of the current message."
(interactive "P")
- (notmuch-mua-new-reply (notmuch-show-get-message-id) prompt-for-sender))
+ (notmuch-mua-new-reply (notmuch-show-get-message-id) nil prompt-for-sender))
+
+(defun notmuch-show-reply-all (&optional prompt-for-sender)
+ "Reply to the sender and all recipients of the current message."
+ (interactive "P")
+ (notmuch-mua-new-reply (notmuch-show-get-message-id) t prompt-for-sender))
(defun notmuch-show-forward-message (&optional prompt-for-sender)
"Forward the current message."
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index fde2377..bd1fd4f 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -206,7 +206,8 @@ For a mouse binding, return nil."
(define-key map ">" 'notmuch-search-last-thread)
(define-key map "p" 'notmuch-search-previous-thread)
(define-key map "n" 'notmuch-search-next-thread)
-(define-key map "r" 'notmuch-search-reply-to-thread)
+(define-key map "r" 'notmuch-search-reply-all-to-thread)
+(define-key map "R" 'notmuch-search-reply-to-thread)
(define-key map "m" 'notmuch-mua-new-mail)
(define-key map "s" 'notmuch-search)
(define-key map "o" 'notmuch-search-toggle-order)
@@ -444,7 +445,13 @@ Complete list of currently available key bindings:
"Begin composing a reply to the entire current thread in a new buffer."
(interactive "P")
(let ((message-id (notmuch-search-find-thread-id)))
-(notmuch-mua-new-reply message-id prompt-for-sender)))
+(notmuch-mua-new-reply message-id nil prompt-for-sender)))
+
+(defun notmuch-search-reply-all-to-thread (&optional prompt-for-sender)
+ "Begin composing a reply-all to the entire current thread in a new buffer."
+ (interactive "P")
+ (let ((message-id (notmuch-search-find-thread-id)))
+(notmuch-mua-new-reply message-id t prompt-for-sender)))
(defun notmuch-call-notmuch-process (&rest args)
"Synchronously invoke \"notmuch\" with the given list of arguments.
--
1.7.5.4
[PATCH] emacs: call "notmuch tag" only once when archiving a thread
On Thu, 05 Jan 2012 15:10:33 -0500, Aaron Ecay wrote: > On Tue, 3 Jan 2012 20:29:06 +0200, Jani Nikula wrote: > > Optimize thread archiving by combining all the -inbox tagging operations to > > a single "notmuch tag" call. > > Perhaps I?m missing something, but is there anything preventing emacs > from just doing the following? > > notmuch tag -inbox thread:000whatever In the search view it does exactly this. In the show view it only modifies the messages that are currently visible. This is to make sure you don't accidentally archive things that have arrived after refreshing the buffer. I think this is safest. I suppose the point in the difference is that in search view you're archiving the thread without seeing the messages anyway. In show view you have had enough interest in the thread to open it, and you're making the decision based on the messages you've seen. BR, Jani.
[PATCH 0/4] notmuch reply bugfix & reply to sender only
On Thu, 5 Jan 2012 22:25:11 +0200, Jani Nikula wrote: > Bikeshedding topic #1: How about making replying to just the sender the > default > in "notmuch reply", and having --reply-all option (instead of --no-reply-all)? > > Bikeshedding topic #2: How about binding 'r' to reply to just the sender by > default, and making 'R' reply-all (instead of vice versa)? I personally like both of these suggestions, and would not be bothered by the changed default, so I support both of these changes. Maybe we could just use '--all', instead of '--reply-all'? The 'reply' part seems kind of redundant with the command: notmuch reply --all vs. notmuch reply --reply-all jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120105/632ad7c0/attachment.pgp>
[PATCH] emacs: call "notmuch tag" only once when archiving a thread
On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote: > In the search view it does exactly this. I worry about race conditions in this case, though. I frequently archive threads after I've read everything, but I still want to know if new message to that thread come in. If I attempt to archive a thread in notmuch-search, but a new message has entered the thread without me knowing it, I'll archive the new message before I had a chance to look at it. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120105/34f2f600/attachment.pgp>
[PATCH] emacs: call "notmuch tag" only once when archiving a thread
On Thu, 05 Jan 2012 12:38:18 -0800, Jameson Graef Rollins wrote: > On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote: > > In the search view it does exactly this. > > I worry about race conditions in this case, though. I frequently > archive threads after I've read everything, but I still want to know if > new message to that thread come in. If I attempt to archive a thread in > notmuch-search, but a new message has entered the thread without me > knowing it, I'll archive the new message before I had a chance to look > at it. Just to be clear: The patch in question does not alter this behaviour. The race you describe is there already. And at a glance, it does not look like something that would be trivial to fix. The buffer does not have the information to do that. BR, Jani.
[PATCH 0/4] notmuch reply bugfix & reply to sender only
Hello > Bikeshedding topic #1: How about making replying to just the sender the > default > in "notmuch reply", and having --reply-all option (instead of --no-reply-all)? In id:"87pqn5cg4g.fsf at yoom.home.cworth.org" cworth suggested using --reply-to=sender vs. --reply-to=all (keeping the latter the default). (This was in response to a patch set I submitted implementing a reply-to-sender option (*)) > Bikeshedding topic #2: How about binding 'r' to reply to just the sender by > default, and making 'R' reply-all (instead of vice versa)? Personally I would prefer this but it is easy to customise. However, one more significant choice is what to do on reply-to-sender to an email from the user himself. My patch used the following logic: look at the reply-to, from , to, cc lines until you find a non-user address and use that line for the reply. My recollection is that this is roughly what mutt does. At least for the common "from user" cases mutt does reply-to-one : just to to: person group-reply: to to: and cc: people Best wishes Mark (*) I have a version of that patch-set which applies to master if that would be useful to anyone, and I recently started writing tests in preparation for re-submitting.
[PATCH] Update NEWS for Emacs changes
On Wed, 4 Jan 2012 10:25:07 +0100, Thomas Jost wrote: > --- > Hello world, > > Here's my part. (Also describes Ivy Foster's patch for > notmuch-hello-mode-hook.) > Pushed to release; some mashing needed to fit with Jamie's changes. Have look and see if anything got too mashed.
[PATCH] emacs: fix notmuch-show-indent-messages-width customization variable name
On Mon, 2 Jan 2012 14:23:02 -0800, Jameson Graef Rollins wrote: > The name was originally notmuch-indent-messages-width, which is > inconsistent with our variable naming convention. > --- > Sorry, I forgot to fix the tests in the original patch. Finally pushed both, with a couple of typo fixes.
[PATCH 0/4] notmuch reply bugfix & reply to sender only
On Thu, Jan 5, 2012 at 13:25, Jani Nikula wrote: > Bikeshedding topic #1: How about making replying to just the sender the > default > in "notmuch reply", and having --reply-all option (instead of --no-reply-all)? > > Bikeshedding topic #2: How about binding 'r' to reply to just the sender by > default, and making 'R' reply-all (instead of vice versa)? I like both these suggestions. This would bring the notmuch behavior in line with gmail, which is what I tend to expect. Mark Walters brings up a good point, that there is a question of what to do when the user tries to reply to their own email. When I do this, what I intend is to send another email to the last person I emailed in the thread, so I think the suggested heuristic of looking at other headers would work. But, maybe others have a different expectation in this case?
Exporting mime email
On Fri, 06 Jan 2012 00:29:39 +, Mark Walters wrote: > What is the best way of exporting/saving as text a mime-encoded email > from the emacs interface (e.g, if I want to save a mime-encoded > email containing a patch)? Maybe you're looking for '|'? That will pipe the raw message to whatever command is specified. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120105/f18c8ff9/attachment.pgp>
[PATCH 1/4] cli: fix use of uninitialized variable in "notmuch reply"
On Thu, 5 Jan 2012 22:25:12 +0200, Jani Nikula wrote:
> -notmuch_show_params_t params;
> +notmuch_show_params_t params = { .part = -1 };
>
> reply_format_func = notmuch_reply_format_default;
> -params.part = -1;
Do I understand correctly that this is just a style change, or do you
rely on some c99(?) behaviour of initializing the other elements to 0?
d
[PATCH] emacs: Helpers for notmuch developers.
On Wed, 4 Jan 2012 14:01:18 +, David Edmondson wrote: > --- > > I've been using this for a few days and decided to share it to get > feedback. Reviewing patches can be tedious, so I tried to make things > a little simpler. > I didn't have a very thorough look at the code, but I like the functionality. Especially hitting q a few times from magit and being in the right place to reply. > General management (i.e. keeping up to date) of the repository it uses > is your responsibility, as is cleaning out old branches. You can, of > course, just delete the temporary repository after using it - the code > will re-create it next time. maybe the branches could be under some namespace that makes this easy? > +(defvar notmuch-dev-temporary-repository-name (concat "notmuch-dev-" > (user-login-name)) > + "The name of the temporary repository.") Do we care about security at all in this context? I'm always a bit nervous about creating predictably named files/directories in publicly writable places. > + ;; Causes us to switch to the magit buffer - is that unfortunate in > + ;; some situations? > + (magit-status notmuch-dev-temporary-repository-path)) I found it to be a pleasant surprise. > + (shell-command > + (concat > + notmuch-command " show --format=mbox " (shell-quote-argument > search-terms) > + " | " > + "git am --quiet")) > + Hmm. A knee jerk reaction is not to like this, like seeing system in C code. But I don't have a better solution off hand. d
