[notmuch] [PATCH] Fix a few documentation typos in notmuch.h

[Fernando Carrijo]

Fix a few documentation typos in notmuch.h


Signed-off-by: Fernando Carrijo 
---
 lib/notmuch.h |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/notmuch.h b/lib/notmuch.h
index 32ab199..873ec09 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -410,7 +410,7 @@ notmuch_query_search_messages (notmuch_query_t *query);
  *
  * This will in turn destroy any notmuch_threads_t and
  * notmuch_messages_t objects generated by this query, (and in
- * turn any notmuch_thrad_t and notmuch_message_t objects generated
+ * turn any notmuch_thread_t and notmuch_message_t objects generated
  * from those results, etc.), if such objects haven't already been
  * destroyed.
  */
@@ -544,7 +544,7 @@ notmuch_thread_get_subject (notmuch_thread_t *thread);
 time_t
 notmuch_thread_get_oldest_date (notmuch_thread_t *thread);

-/* Get the date of the oldest message in 'thread' as a time_t value.
+/* Get the date of the newest message in 'thread' as a time_t value.
  */
 time_t
 notmuch_thread_get_newest_date (notmuch_thread_t *thread);
@@ -871,7 +871,7 @@ notmuch_message_freeze (notmuch_message_t *message);
  * NOTMUCH_STATUS_SUCCESS: Message successfully thawed, (or at least
  * its frozen count has successfully been reduced by 1).
  *
- * NOTMUCH_STATUS_UNBALANCE_FREEZE_THAW: An attempt was made to thaw
+ * NOTMUCH_STATUS_UNBALANCED_FREEZE_THAW: An attempt was made to thaw
  * an unfrozen message. That is, there have been an unbalanced
  * number of calls to notmuch_message_freeze and
  * notmuch_message_thaw.
-- 
1.5.6.3

[notmuch] slowdown with large html heavy threads

[Alexander Botero-Lowry]

Carl mentioned that he saw some nasty performance issues with threads
that had a lot of HTML messages in them.

If you are experiencing this problem, would you mind trying some
alternative mm-text-html-renderer setting:

http://mh-e.sourceforge.net/manual/html/HTML.html

Also, if you have elinks, I recommend my custom renderer:

(require 'mm-view)
(add-to-list 'mm-text-html-renderer-alist 
  '(elinks mm-inline-render-with-stdin nil "elinks" "-force-html" "-dump"))
(setq mm-text-html-renderer 'elinks)


Alex

[notmuch] [PATCH -V2] notmuch-reply: Add support for replying only to sender

[Aneesh Kumar K.V]

From: Aneesh Kumar K.V 

This patch add --format=sender-only option.

Signed-off-by: Aneesh Kumar K.V 
---
 notmuch-reply.c |   54 --
 1 files changed, 40 insertions(+), 14 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index 0cda72d..859b725 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -23,15 +23,23 @@
 #include "notmuch-client.h"
 #include "gmime-filter-reply.h"

-static const struct {
+struct reply_map {
 const char *header;
 const char *fallback;
 GMimeRecipientType recipient_type;
-} reply_to_map[] = {
+};
+
+static const struct reply_map reply_to_all_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 }
+{ "bcc",NULL, GMIME_RECIPIENT_TYPE_BCC },
+{ NULL, NULL, 0}
+};
+
+static const struct reply_map reply_to_sender_map[] = {
+{ "reply-to", "from", GMIME_RECIPIENT_TYPE_TO  },
+{ NULL, NULL, 0}
 };

 static void
@@ -200,7 +208,8 @@ add_recipients_for_string (GMimeMessage *message,
 }

 static int
-notmuch_reply_format_default(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query)
+__notmuch_reply(void *ctx, notmuch_config_t *config,
+   notmuch_query_t *query, const struct reply_map *map)
 {
 GMimeMessage *reply;
 notmuch_messages_t *messages;
@@ -229,17 +238,19 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t 
*config, notmuch_query_
subject = talloc_asprintf (ctx, "Re: %s", subject);
g_mime_message_set_subject (reply, subject);

-   for (i = 0; i < ARRAY_SIZE (reply_to_map); i++) {
+   for (i = 0;; i++) {
const char *addr;

+   if (!map[i].header)
+   break;
recipients = notmuch_message_get_header (message,
-reply_to_map[i].header);
-   if ((recipients == NULL || recipients[0] == '\0') && 
reply_to_map[i].fallback)
+   map[i].header);
+   if ((recipients == NULL || recipients[0] == '\0') && 
map[i].fallback)
recipients = notmuch_message_get_header (message,
-
reply_to_map[i].fallback);
+map[i].fallback);

addr = add_recipients_for_string (reply, config,
- reply_to_map[i].recipient_type,
+ map[i].recipient_type,
  recipients);
if (from_addr == NULL)
from_addr = addr;
@@ -289,6 +300,12 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t 
*config, notmuch_query_
 return 0;
 }

+static int
+notmuch_reply_format_default(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query)
+{
+   return __notmuch_reply(ctx, config, query, reply_to_all_map);
+}
+
 /* This format is currently tuned for a git send-email --notmuch hook */
 static int
 notmuch_reply_format_headers_only(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query)
@@ -332,17 +349,18 @@ notmuch_reply_format_headers_only(void *ctx, 
notmuch_config_t *config, notmuch_q
g_mime_object_set_header (GMIME_OBJECT (reply),
  "References", references);

-   for (i = 0; i < ARRAY_SIZE (reply_to_map); i++) {
+   for (i = 0; i < ARRAY_SIZE (reply_to_all_map); i++) {
const char *addr;

recipients = notmuch_message_get_header (message,
-reply_to_map[i].header);
-   if ((recipients == NULL || recipients[0] == '\0') && 
reply_to_map[i].fallback)
+
reply_to_all_map[i].header);
+   if ((recipients == NULL || recipients[0] == '\0') &&
+   reply_to_all_map[i].fallback)
recipients = notmuch_message_get_header (message,
-
reply_to_map[i].fallback);
+reply_to_all_map[i].fallback);

addr = add_recipients_for_string (reply, config,
- reply_to_map[i].recipient_type,
+ 
reply_to_all_map[i].recipient_type,
  recipients);
}

@@ -361,6 +379,12 @@ notmuch_reply_format_headers_only(void *ctx, 
notmuch_config_t *config, notmuch_q
 return 0;
 }

+static int
+notmuch_reply_format_sender_only(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query)
+{
+   return __notmuch_reply(ctx, config, query, 

[notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Carl Worth]

On Sat, 05 Dec 2009 09:59:12 +0100, Ingmar Vanhassel  
wrote:
> Excerpts from Carl Worth's message of Sat Dec 05 01:56:56 +0100 2009:
> > Cool. At least not everyone thinks I'm crazy then. That's
> > encouraging. :-)
> 
> I'm not convinced that re-implementing lots of things that autoconf
> already handles properly & portably is the better route to go. It's
> purely a waste of time. Hence, I'll be happy to send patches to use
> autoconf, if you change your mind on the subject.

Let's test it.

If you could write a patch to replace our current configure script with
something based on autoconf, then I'll be glad to try it out and see
what I think.

If there are any differences that I find annoying, then we can see which
of those we can work around or get fixed in upstream autoconf.

I'm definitely open to exploration in this area.

> Now when you say you hate automake & libtool, then I'll wholeheartedly
> agree with you.

Hate is one emotion that I do my best to avoid. But I am quite glad to
have found no compelling reason to use either automake or libtool so
far in notmuch. :-)

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091205/77e16b93/attachment.pgp>

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

[Keith Amidon]

Prompt for a directory and write all attachments of the current
message to that directory, prompting for a filename for each with a
default value of the filename specified in the attachment.

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

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

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

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

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

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

[Keith Amidon]

Previously only mime parts that indicated specified a "disposition" of
"attachment" were saved.  However there are time when it is important
to be able to save inline content as well.  After this commit any mime
part that specifies a filename will be considered when saving
attachments.
---
 notmuch.el |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

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

[notmuch] Simple improvements to saving attachments

[Keith Amidon]

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

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

   --- Keith

[notmuch] [PATCH] Update documentation of notmuch_query_create

[Fernando Carrijo]

Commit cd467caf renamed notmuch_query_search to notmuch_query_search_messages.  
  
Commit 1ba3d46f created notmuch_query_search_threads. We better keep the docs   
  
of notmuch_query_create consistent with those changes.  
  


Signed-off-by: Fernando Carrijo   
 
---
 lib/notmuch.h |3 ++-   
  
 1 files changed, 2 insertions(+), 1 deletions(-)   
  

diff --git a/lib/notmuch.h b/lib/notmuch.h  
  
index 60834fb..32ab199 100644   
  
--- a/lib/notmuch.h 
  
+++ b/lib/notmuch.h 
  
@@ -305,7 +305,8 @@ notmuch_database_get_all_tags (notmuch_database_t *db);
  * result in a query that returns all messages in the database.
  
  * 
  
  * See notmuch_query_set_sort for controlling the order of results and 
  
- * notmuch_query_search to actually execute the query. 
  
+ * notmuch_query_search_{messages,threads} to actually execute the 
  
+ * query.  
  
  * 
  
  * User should call notmuch_query_destroy when finished with this  
  
  * query.  
  
--  
  
1.5.6.3

[notmuch] [PATCH] notmuch-show-get-header: new function; return alist of parsed header fields.

[David Bremner]

This function parses the displayed message to recover header
fields. It uses mailheader.el to do the actual header parsing, after
preprocessing to remove indentation.  It relies on the variables
notmuch-show-message-begin-regexp, notmuch-show-header-begin-regexp,
and notmuch-show-message-end-regexp.
---

This is another patch needed for org-mode links. Really I just need
some way to get the author and subject of the current message in
notmuch-show-mode.  It seems like a generally useful function,
although of course it would be more efficient to cache these headers
somewhere if the function is being invoked many times.

 notmuch.el |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index f7048d5..cf472f7 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -203,6 +203,30 @@ Unlike builtin `previous-line' this version accepts no 
arguments."
 (re-search-forward notmuch-show-tags-regexp)
 (split-string (buffer-substring (match-beginning 1) (match-end 1)

+(defun notmuch-show-get-header ()
+  "Retrieve and parse the header from the current message. Returns an alist 
with of (header . value) 
+where header is a symbol and value is a string.  The summary from notmuch-show 
is returned as the 
+pseudoheader summary"
+  (require 'mailheader)
+  (save-excursion
+(beginning-of-line)
+(if (not (looking-at notmuch-show-message-begin-regexp))
+   (re-search-backward notmuch-show-message-begin-regexp))
+(re-search-forward (concat notmuch-show-header-begin-regexp 
"\n[[:space:]]*\\(.*\\)\n"))
+(let* ((summary (buffer-substring-no-properties (match-beginning 1) 
(match-end 1)))
+ (beg (point)))
+  (re-search-forward notmuch-show-header-end-regexp)
+  (let ((text (buffer-substring beg (match-beginning 0
+   (with-temp-buffer
+ (insert text)
+ (goto-char (point-min))
+ (while (looking-at "\\([[:space:]]*\\)[A-Za-z][-A-Za-z0-9]*:")
+   (delete-region (match-beginning 1) (match-end 1))
+   (forward-line)
+   )
+ (goto-char (point-min))
+ (cons (cons 'summary summary) 
(mail-header-extract-no-properties)))
+  
 (defun notmuch-show-add-tag ( toadd)
   "Add a tag to the current message."
   (interactive
-- 
1.6.5.3

[notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Ingmar Vanhassel]

Excerpts from Carl Worth's message of Sat Dec 05 01:56:56 +0100 2009:
> Cool. At least not everyone thinks I'm crazy then. That's
> encouraging. :-)

I'm not convinced that re-implementing lots of things that autoconf
already handles properly & portably is the better route to go. It's
purely a waste of time. Hence, I'll be happy to send patches to use
autoconf, if you change your mind on the subject.

Now when you say you hate automake & libtool, then I'll wholeheartedly
agree with you.

-Ingmar
-- 
Exherbo KDE, X.org maintainer

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Marten Veldthuis]

On Fri, 04 Dec 2009 16:39:50 -0800, Carl Worth  wrote:
> But when viewing an actual message, I'm still planning on having notmuch
> just return an arbitrary filename from the list of filenames associated
> with that message. Does anyone see any problem with that? Can you think
> of a case where you'd really care about seeing one or the other of
> a particular duplicated message?

As long as it's deterministic. But if you don't display the first
filename received, couldn't you exploit this by spoofing message ids?

-- 
- Marten

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Mikhail Gusarov]

Twas brillig at 16:39:50 04.12.2009 UTC-08 when cworth at cworth.org did gyre 
and gimble:

 CW> But when viewing an actual message, I'm still planning on having
 CW> notmuch just return an arbitrary filename from the list of
 CW> filenames associated with that message. Does anyone see any problem
 CW> with that? Can you think of a case where you'd really care about
 CW> seeing one or the other of a particular duplicated message?

There might be different Reply-To fields.

So I'd just return bigger dup, as it probably contains more information
:)

-- 
  http://fossarchy.blogspot.com/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091205/314701c6/attachment.pgp>

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Mikhail Gusarov]

Twas brillig at 10:35:27 04.12.2009 UTC-08 when cworth at cworth.org did gyre 
and gimble:

 >> The only problem with Cc is that Mailman suppresses duplicate
 >> messages and hence there is no List-Id: on message.

 CW> But the above sounds like the List-Id header is unreliable enough
 CW> to be useless.  Any reason not to just use something like
 CW> to:notmuch at notmuchmail to match messages sent to a list like this
 CW> one?

Automated processing. I'd go crazy to put all mailing lists' addresses
to .procmailrc instead of simple sorter in sed. But it seems it's the
only reliable way.

 CW> I think mailman defaults to not allowing messages with the
 CW> mailing-list address implicit (such as in a Bcc) so it seems like
 CW> matching the list recipient will be more reliable than hoping the
 CW> List-Id is always there.

Yep. Unfortunately.

-- 
  http://fossarchy.blogspot.com/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091205/1283340b/attachment.pgp>

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Mikhail Gusarov]

Twas brillig at 10:05:05 04.12.2009 UTC-08 when cworth at cworth.org did gyre 
and gimble:

 CW> Plus, notmuch already handles duplicate mail just fine, (in that the
 CW> user only sees one copy at least). And I tag my mail differently when
 CW> one of my addresses appears on the CC list, so I definitely prefer that
 CW> people CC me when they want to call my specific attention to a message.

The only problem with Cc is that Mailman suppresses duplicate messages and hence
there is no List-Id: on message.

-- 
  http://fossarchy.blogspot.com/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091205/33bebe44/attachment.pgp>

Re: [notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Ingmar Vanhassel]

Excerpts from Carl Worth's message of Sat Dec 05 01:56:56 +0100 2009:
 Cool. At least not everyone thinks I'm crazy then. That's
 encouraging. :-)

I'm not convinced that re-implementing lots of things that autoconf
already handles properly  portably is the better route to go. It's
purely a waste of time. Hence, I'll be happy to send patches to use
autoconf, if you change your mind on the subject.

Now when you say you hate automake  libtool, then I'll wholeheartedly
agree with you.

-Ingmar
-- 
Exherbo KDE, X.org maintainer
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Sat, 05 Dec 2009 09:51:58 +0100, Marten Veldthuis mar...@veldthuis.com 
wrote:
 On Fri, 04 Dec 2009 16:39:50 -0800, Carl Worth cwo...@cworth.org wrote:
  But when viewing an actual message, I'm still planning on having notmuch
  just return an arbitrary filename from the list of filenames associated
  with that message. Does anyone see any problem with that? Can you think
  of a case where you'd really care about seeing one or the other of
  a particular duplicated message?
 
 As long as it's deterministic. But if you don't display the first
 filename received, couldn't you exploit this by spoofing message ids?

What it currently does is use the filename of the first file that
notmuch encounters. That's different than first received, but either
way, there's still a race condition here for active spoofing attempts.

And, yes, actual intentional collisions of message IDs is something I
hadn't given thought to yet. So thanks for bringing that up. It's
definitely a case where you'd want to know and see the difference.

So maybe what we really want to do is to display some full-context diff
of the message by default, and have notmuch learn about differences the
user isn't interested in seeing, (such as mailing-list footers or so).

That sounds workable and should make any spoofing attempt obvious to the
user.

-Carl



pgpNa2wqChbW7.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch