[PATCH] emacs: Helpers for notmuch developers.

2012-01-05 Thread David Bremner
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


[PATCH 1/4] cli: fix use of uninitialized variable in "notmuch reply"

2012-01-05 Thread David Bremner
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: call "notmuch tag" only once when archiving a thread

2012-01-05 Thread Jani Nikula
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] emacs: call "notmuch tag" only once when archiving a thread

2012-01-05 Thread Jani Nikula
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 4/4] emacs: add support for replying just to the sender of messages and threads

2012-01-05 Thread Jani Nikula
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  sender)
+(defun notmuch-mua-reply (query-string  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  prompt-for-sender)
+(defun notmuch-mua-new-reply (query-string  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 ( 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 ( 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 ( 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 ( 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 ( 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 ( args)
   "Synchronously invoke \"notmuch\" with the given list of arguments.
-- 
1.7.5.4



[PATCH 3/4] cli: add support for replying just to the sender in "notmuch reply"

2012-01-05 Thread Jani Nikula
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 2/4] cli: convert "notmuch reply" to use the new argument parser

2012-01-05 Thread Jani Nikula
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", 'f',
+ (notmuch_keyword_t []){ { "default", FORMAT_DEFAULT },
+ { "headers-only", FORMAT_HEADERS_ONLY },
+ { 0, 0 } } },
+   { NOTMUCH_OPT_BOOLEAN, , "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 1/4] cli: fix use of uninitialized variable in "notmuch reply"

2012-01-05 Thread Jani Nikula
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 0/4] notmuch reply bugfix & reply to sender only

2012-01-05 Thread Jani Nikula
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 0/4] notmuch reply bugfix & reply to sender only

2012-01-05 Thread Mark Walters

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] emacs: fix notmuch-show-indent-messages-width customization variable name

2012-01-05 Thread David Bremner
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] Update NEWS for Emacs changes

2012-01-05 Thread David Bremner
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.


Info about notmuch database

2012-01-05 Thread Thomas Jost
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 0/4] notmuch reply bugfix & reply to sender only

2012-01-05 Thread Adam Wolfe Gordon
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

2012-01-05 Thread Jameson Graef Rollins
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>


Info about notmuch database

2012-01-05 Thread boyska
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

2012-01-05 Thread Thomas Jost
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>


[PATCH] emacs: call "notmuch tag" only once when archiving a thread

2012-01-05 Thread Aaron Ecay
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] emacs: call "notmuch tag" only once when archiving a thread

2012-01-05 Thread Jameson Graef Rollins
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 0/4] notmuch reply bugfix & reply to sender only

2012-01-05 Thread Jameson Graef Rollins
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>


[ANNOUNCE] mutt with notmuch support

2012-01-05 Thread Tim Gray
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>


Re: [PATCH] emacs: call notmuch tag only once when archiving a thread

2012-01-05 Thread Tomi Ollila
On Tue,  3 Jan 2012 20:29:06 +0200, Jani Nikula j...@nikula.org 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 j...@nikula.org

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


Re: [PATCH] NEWS: consistent 2-space indentation

2012-01-05 Thread Jameson Graef Rollins
On Wed,  4 Jan 2012 15:26:52 +0200, Tomi Ollila tomi.oll...@iki.fi 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

2012-01-05 Thread Jameson Graef Rollins
On Tue, 3 Jan 2012 20:59:51 +0100, Karel Zak k...@redhat.com 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: [ANNOUNCE] mutt with notmuch support

2012-01-05 Thread Tim Gray

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

2012-01-05 Thread Thomas Jost
On Wed, 04 Jan 2012 15:49:19 +, boyska piutto...@logorroici.org 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

2012-01-05 Thread boyska
On Thu, Jan 05, 2012 at 04:04:22PM +0100, Thomas Jost wrote:
 On Wed, 04 Jan 2012 15:49:19 +, boyska piutto...@logorroici.org 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

2012-01-05 Thread Thomas Jost
On Thu, 5 Jan 2012 16:38:07 +0100, boyska piutto...@logorroici.org 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

2012-01-05 Thread Aaron Ecay
On Tue,  3 Jan 2012 20:29:06 +0200, Jani Nikula j...@nikula.org 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

2012-01-05 Thread Jani Nikula
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

2012-01-05 Thread Jani Nikula
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 j...@nikula.org
---
 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

2012-01-05 Thread Jani Nikula
Use the new notmuch argument parser to handle arguments in notmuch
reply. There should be no functional changes.

Signed-off-by: Jani Nikula j...@nikula.org
---
 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

2012-01-05 Thread Jani Nikula
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 j...@nikula.org
---
 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

2012-01-05 Thread Jani Nikula
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 j...@nikula.org
---
 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

2012-01-05 Thread Jani Nikula
On Thu, 05 Jan 2012 15:10:33 -0500, Aaron Ecay aarone...@gmail.com wrote:
 On Tue,  3 Jan 2012 20:29:06 +0200, Jani Nikula j...@nikula.org 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

2012-01-05 Thread Jameson Graef Rollins
On Thu,  5 Jan 2012 22:25:11 +0200, Jani Nikula j...@nikula.org 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

2012-01-05 Thread Jameson Graef Rollins
On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula j...@nikula.org 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

2012-01-05 Thread Jani Nikula
On Thu, 05 Jan 2012 12:38:18 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula j...@nikula.org 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

2012-01-05 Thread Mark Walters

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

2012-01-05 Thread David Bremner
On Wed,  4 Jan 2012 10:25:07 +0100, Thomas Jost schno...@schnouki.net 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

2012-01-05 Thread David Bremner
On Mon,  2 Jan 2012 14:23:02 -0800, Jameson Graef Rollins 
jroll...@finestructure.net 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

2012-01-05 Thread Adam Wolfe Gordon
On Thu, Jan 5, 2012 at 13:25, Jani Nikula j...@nikula.org 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

2012-01-05 Thread Mark Walters

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

2012-01-05 Thread Jameson Graef Rollins
On Fri, 06 Jan 2012 00:29:39 +, Mark Walters markwalters1...@gmail.com 
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

2012-01-05 Thread Mark Walters

Hi

On Thu, 05 Jan 2012 16:44:10 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Fri, 06 Jan 2012 00:29:39 +, Mark Walters markwalters1...@gmail.com 
 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

2012-01-05 Thread David Bremner
On Thu,  5 Jan 2012 22:25:12 +0200, Jani Nikula j...@nikula.org 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.

2012-01-05 Thread David Bremner
On Wed,  4 Jan 2012 14:01:18 +, David Edmondson d...@dme.org 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