[PATCH v2] emacs: Make the part content available to the mm-inline* checks.

[Dmitry Kurochkin]

On Wed, 18 Jan 2012 14:35:01 -0500, Austin Clements  wrote:
> Quoth Dmitry Kurochkin on Jan 18 at 11:00 pm:
> > On Wed, 18 Jan 2012 18:30:36 +, David Edmondson  wrote:
> > > On Wed, 18 Jan 2012 22:04:36 +0400, Dmitry Kurochkin  > > gmail.com> wrote:
> > > > On Wed, 18 Jan 2012 17:39:31 +, David Edmondson  
> > > > wrote:
> > > > > The `mm-inlinable-p' and `mm-inlined-p' functions work better if they
> > > > > have access to the data of the relevant part, so load that content
> > > > > before calling either function.
> > > > > 
> > > > > This fixes the display of attached image/jpeg parts, for example.
> > > > 
> > > > Not so long ago I made an opposite change to avoid fetching useless
> > > > parts (e.g. audio files).  Looks like we need a better check here.  Can
> > > > we know from Content-Type if fetching a part body would be useful?
> > > 
> > > What if `notmuch-show-insert-part-*/*' consulted a list of content-type
> > > regexps to attempt to inline?
> > > 
> > > That would allow a sane default (("image/*" "text/*") perhaps), but also
> > > allow more to be added to that list (or some to be removed), either by
> > > code that detected the (in)ability to render it or the user.
> > 
> > Perhaps there is such a list in mm already?
> 
> Shouldn't we only be doing this for parts with inline (or not
> attachment) content-disposition?  That's cheap to check.  Or do we
> actually want things like image attachments to get inlined, despite
> their disposition?

It may be good to have this behavior configurable.  I would like Emacs
to display all part types that it can, independent from
content-disposition.

Anyway, this is a separate issue.  In any case we want to fetch part
body only if it is useful.

Regards,
  Dmitry

[PATCH v2] emacs: Make the part content available to the mm-inline* checks.

[Dmitry Kurochkin]

On Wed, 18 Jan 2012 18:30:36 +, David Edmondson  wrote:
> On Wed, 18 Jan 2012 22:04:36 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > On Wed, 18 Jan 2012 17:39:31 +, David Edmondson  wrote:
> > > The `mm-inlinable-p' and `mm-inlined-p' functions work better if they
> > > have access to the data of the relevant part, so load that content
> > > before calling either function.
> > > 
> > > This fixes the display of attached image/jpeg parts, for example.
> > 
> > Not so long ago I made an opposite change to avoid fetching useless
> > parts (e.g. audio files).  Looks like we need a better check here.  Can
> > we know from Content-Type if fetching a part body would be useful?
> 
> What if `notmuch-show-insert-part-*/*' consulted a list of content-type
> regexps to attempt to inline?
> 
> That would allow a sane default (("image/*" "text/*") perhaps), but also
> allow more to be added to that list (or some to be removed), either by
> code that detected the (in)ability to render it or the user.

Perhaps there is such a list in mm already?

Regards,
  Dmitry

RFC: tag macros

[David Bremner]

On Wed, 18 Jan 2012 18:15:37 -0800, Jameson Graef Rollins  wrote:
> 
> Can't we just use the emacs build-in documentation?
> 

If you mean docstrings, that is only per function/variable.  Which is
better than nothing, but not very good for getting an overview of what
is going on.  Otherwise, info _is_ emacs' built-in documentation.

d

[PATCH v2] emacs: Make the part content available to the mm-inline* checks.

[Dmitry Kurochkin]

Hi David.

On Wed, 18 Jan 2012 17:39:31 +, David Edmondson  wrote:
> The `mm-inlinable-p' and `mm-inlined-p' functions work better if they
> have access to the data of the relevant part, so load that content
> before calling either function.
> 
> This fixes the display of attached image/jpeg parts, for example.

Not so long ago I made an opposite change to avoid fetching useless
parts (e.g. audio files).  Looks like we need a better check here.  Can
we know from Content-Type if fetching a part body would be useful?

Regards,
  Dmitry

> ---
> 
> Removed the cruft that crept into the previous patch.
> 
>  emacs/notmuch-show.el |   14 ++
>  1 files changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 2df8d3b..f280df2 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -330,14 +330,12 @@ current buffer, if possible."
>  (with-temp-buffer
>(let* ((charset (plist-get part :content-charset))
>(handle (mm-make-handle (current-buffer) `(,content-type (charset 
> . ,charset)
> - (if (and (mm-inlinable-p handle)
> -  (mm-inlined-p handle))
> - (let ((content (notmuch-show-get-bodypart-content msg part nth)))
> -   (insert content)
> -   (set-buffer display-buffer)
> -   (mm-display-part handle)
> -   t)
> -   nil)
> + (insert (notmuch-show-get-bodypart-content msg part nth))
> + (when (and (mm-inlinable-p handle)
> +(mm-inlined-p handle))
> +   (set-buffer display-buffer)
> +   (mm-display-part handle)
> +   t)
>  
>  (defvar notmuch-show-multipart/alternative-discouraged
>'(
> -- 
> 1.7.8.3
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 2/3] emacs: use a single history for all searches

[Dmitry Kurochkin]

On Wed, 18 Jan 2012 08:25:22 +, David Edmondson  wrote:
> On Tue, 17 Jan 2012 23:34:09 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > There are two ways to do search in Emacs UI: search widget in
> > notmuch-hello buffer and `notmuch-search' function bound to "s".
> > Before the change, these search mechanisms used different history
> > lists.  The patch makes notmuch-hello search use the same history list
> > as `notmuch-search' function.
> 
> The test output updates included here should be with the previous patch,
> shouldn't they?
> 

Indeed.  Would send v2.

> > -(defun notmuch-search (query  oldest-first target-thread 
> > target-line continuation)
> > -  "Run \"notmuch search\" with the given query string and display results.
> > +(defun notmuch-search ( query oldest-first target-thread 
> > target-line continuation)
> > +  "Run \"notmuch search\" with the given `query' and display results.
> >  
> > -The optional parameters are used as follows:
> > +If `query' is nil, it is read interactively from the minibuffer.
> > +Other optional parameters are used as follows:
> >  
> >oldest-first: A Boolean controlling the sort order of returned threads
> >target-thread: A thread ID (with the thread: prefix) that will be made
> >   current if it appears in the search results.
> >target-line: The line number to move to if the target thread does not
> > appear in the search results."
> > -  (interactive (list (notmuch-read-query "Notmuch search: ")))
> > +  (interactive)
> > +  (if (null query)
> > +  (setq query (notmuch-read-query "Notmuch search: "))
> > +(setq query (notmuch-trim query))
> > +(let ((history-delete-duplicates t))
> > +  (add-to-history 'notmuch-search-history query)))
> 
> Should user-typed queries be trimmed?

IMO that would not hurt.  But we need to do it before it gets added to
the history.  And that may be tricky.  So this patch does trimming only
for queries from notmuch-hello search box (as it was before).

Regards,
  Dmitry

[PATCH 3/3] show: Introduce mime_node formatter callback

[Austin Clements]

Quoth Jani Nikula on Jan 19 at 12:33 am:
> On Wed, 18 Jan 2012 15:28:27 -0500, Austin Clements  
> wrote:
> > This callback is the gateway to the new mime_node_t-based formatters.
> > This maintains backwards compatibility so the formatters can be
> > transitioned one at a time.  Once all formatters are converted, the
> > formatter structure can be reduced to only message_set_{start,sep,end}
> > and part, most of show_message can be deleted, and all of
> > show-message.c can be deleted.
> > ---
> >  notmuch-client.h |6 ++
> >  notmuch-reply.c  |2 +-
> >  notmuch-show.c   |   22 ++
> >  3 files changed, 25 insertions(+), 5 deletions(-)
> > 
> > diff --git a/notmuch-client.h b/notmuch-client.h
> > index b3dcb6b..3ccdfad 100644
> > --- a/notmuch-client.h
> > +++ b/notmuch-client.h
> > @@ -54,8 +54,14 @@
> >  #define STRINGIFY(s) STRINGIFY_(s)
> >  #define STRINGIFY_(s) #s
> >  
> > +struct mime_node;
> > +struct notmuch_show_params;
> > +
> >  typedef struct notmuch_show_format {
> >  const char *message_set_start;
> > +void (*part) (const void *ctx,
> > + struct mime_node *node, int indent,
> > + struct notmuch_show_params *params);
> >  const char *message_start;
> >  void (*message) (const void *ctx,
> >  notmuch_message_t *message,
> > diff --git a/notmuch-reply.c b/notmuch-reply.c
> > index 0f682db..9a224e2 100644
> > --- a/notmuch-reply.c
> > +++ b/notmuch-reply.c
> > @@ -31,7 +31,7 @@ static void
> >  reply_part_content (GMimeObject *part);
> >  
> >  static const notmuch_show_format_t format_reply = {
> > -"",
> > +"", NULL,
> > "", NULL,
> > "", NULL, reply_headers_message_part, ">\n",
> > "",
> > diff --git a/notmuch-show.c b/notmuch-show.c
> > index ecadfa8..46eef44 100644
> > --- a/notmuch-show.c
> > +++ b/notmuch-show.c
> > @@ -42,7 +42,7 @@ static void
> >  format_part_end_text (GMimeObject *part);
> >  
> >  static const notmuch_show_format_t format_text = {
> > -"",
> > +"", NULL,
> > "\fmessage{ ", format_message_text,
> > "\fheader{\n", format_headers_text, 
> > format_headers_message_part_text, "\fheader}\n",
> > "\fbody{\n",
> > @@ -85,7 +85,7 @@ static void
> >  format_part_end_json (GMimeObject *part);
> >  
> >  static const notmuch_show_format_t format_json = {
> > -"[",
> > +"[", NULL,
> > "{", format_message_json,
> > "\"headers\": {", format_headers_json, 
> > format_headers_message_part_json, "}",
> > ", \"body\": [",
> > @@ -106,7 +106,7 @@ format_message_mbox (const void *ctx,
> >  unused (int indent));
> >  
> >  static const notmuch_show_format_t format_mbox = {
> > -"",
> > +"", NULL,
> >  "", format_message_mbox,
> >  "", NULL, NULL, "",
> >  "",
> > @@ -125,7 +125,7 @@ static void
> >  format_part_content_raw (GMimeObject *part);
> >  
> >  static const notmuch_show_format_t format_raw = {
> > -"",
> > +"", NULL,
> > "", NULL,
> > "", NULL, format_headers_message_part_text, "\n",
> >  "",
> > @@ -762,6 +762,20 @@ show_message (void *ctx,
> >   int indent,
> >   notmuch_show_params_t *params)
> >  {
> > +if (format->part) {
> > +   void *local = talloc_new (ctx);
> > +   mime_node_t *root, *part;
> > +
> > +   if (mime_node_open (local, message, params->cryptoctx, params->decrypt,
> > +   ) != NOTMUCH_STATUS_SUCCESS)
> 
> I'm new to talloc, I think I like it, but I always find it confusing
> when some code paths free the contexts, and some don't. Like here.
> 
> Are you not freeing the local context here because it's just an empty
> context, and freeing below because it's no longer empty?

No, that's just a bug.  In practice it probably doesn't matter much
because, as you pointed out, the local context consumes very little
memory and since the caller will eventually free ctx, local will get
cleaned up, too.  So, while this isn't strictly a memory leak, in
principle this could add up before ctx gets freed.  Fixed.

> No need to change anything, I guess, just asking...

I wait a little for other comments and then send a new version.

Thanks for the review!

> BR,
> Jani.
> 
> > +   return;
> > +   part = mime_node_seek_dfs (root, params->part < 0 ? 0 : params->part);
> > +   if (part)
> > +   format->part (local, part, indent, params);
> > +   talloc_free (local);
> > +   return;
> > +}
> > +
> >  if (params->part <= 0) {
> > fputs (format->message_start, stdout);
> > if (format->message)

[PATCH 1/3] mime node: Record depth-first part numbers

[Austin Clements]

Quoth Jani Nikula on Jan 19 at 12:25 am:
> On Wed, 18 Jan 2012 15:28:25 -0500, Austin Clements  
> wrote:
> > This makes the part numbers readily accessible to formatters.
> > Hierarchical part numbering would be a more natural and efficient fit
> > for MIME and may be the way to go in the future, but depth-first
> > numbering maintains compatibility with what we currently do.
> 
> Hi, please find a few things to consider below. If you disagree after
> considering, it's quite all right, as they're largely style matters. :)
> 
> BR,
> Jani.
> 
> 
> > ---
> >  mime-node.c  |   33 -
> >  notmuch-client.h |   11 +++
> >  2 files changed, 43 insertions(+), 1 deletions(-)
> > 
> > diff --git a/mime-node.c b/mime-node.c
> > index d26bb44..30b542f 100644
> > --- a/mime-node.c
> > +++ b/mime-node.c
> > @@ -104,6 +104,10 @@ mime_node_open (const void *ctx, notmuch_message_t 
> > *message,
> >  root->nchildren = 1;
> >  root->ctx = mctx;
> >  
> > +root->part_num = 0;
> > +root->next_child = 0;
> > +root->next_part_num = 1;
> > +
> >  *root_out = root;
> >  return NOTMUCH_STATUS_SUCCESS;
> >  
> > @@ -133,6 +137,8 @@ _mime_node_create (const mime_node_t *parent, 
> > GMimeObject *part)
> > talloc_free (node);
> > return NULL;
> >  }
> > +node->parent = parent;
> > +node->part_num = node->next_part_num = -1;
> >  
> >  /* Deal with the different types of parts */
> >  if (GMIME_IS_PART (part)) {
> > @@ -217,6 +223,7 @@ mime_node_t *
> >  mime_node_child (const mime_node_t *parent, int child)
> >  {
> >  GMimeObject *sub;
> > +mime_node_t *node;
> >  
> >  if (!parent || child < 0 || child >= parent->nchildren)
> > return NULL;
> > @@ -234,7 +241,31 @@ mime_node_child (const mime_node_t *parent, int child)
> > INTERNAL_ERROR ("Unexpected GMimeObject type: %s",
> > g_type_name (G_OBJECT_TYPE (parent->part)));
> >  }
> > -return _mime_node_create (parent, sub);
> > +node = _mime_node_create (parent, sub);
> > +
> > +if (child == parent->next_child && parent->next_part_num != -1) {
> > +   /* We're traversing in depth-first order.  Record the child's
> > +* depth-first numbering. */
> > +   node->part_num = parent->next_part_num;
> > +   node->next_part_num = node->part_num + 1;
> > +
> > +   /* Drop the const qualifier because these are internal fields
> > +* whose mutability doesn't affect the interface. */
> 
> FWIW, I'm not a big fan of casting away const. Either it is const, or it
> isn't. Not very many places would be affected if you dropped the const
> qualifier from the related interface(s) altogether, and things would
> look cleaner here. But I suppose this is a matter of taste.

I'm not particularly happy with this either.  Unfortunately, dropping
the const here affects a surprising number of places, including the
entire MIME node API.

I think that, at a deep level, depth-first numbering simply doesn't
resonate with an extremely hierarchical API like this and that
dissonance is going to have to focus somewhere.  There have been
discussions of switching to hierarchical part numbering before (in
particular, because depth-first numbering is unstable with encrypted
parts) and I'll probably restart those after all of this is done.

> > +   ((mime_node_t*)parent)->next_child++;
> > +   ((mime_node_t*)parent)->next_part_num = -1;
> > +
> > +   if (node->nchildren == 0) {
> > +   /* We've reached a leaf, so find the parent that has more
> > +* children and set it up to number its next child. */
> > +   const mime_node_t *it = node;
> > +   while (it && it->next_child == it->nchildren)
> > +   it = it->parent;
> > +   if (it)
> > +   ((mime_node_t*)it)->next_part_num = node->part_num + 1;
> > +   }
> > +}
> 
> Following the constness around made me wonder why the above if block
> isn't within _mime_node_create(). It does have a feel of initialization
> related to creation in it. (You'd have to pass more info to it though.)

I considered this, but was dissuaded by having to pass redundant
information to _mime_node_create.  I think it's okay here because it
has as much to do with child fetching as with initialization, but I
could easily be swayed.

> > +
> > +return node;
> >  }
> >  
> >  static mime_node_t *
> > diff --git a/notmuch-client.h b/notmuch-client.h
> > index 62ede28..b3dcb6b 100644
> > --- a/notmuch-client.h
> > +++ b/notmuch-client.h
> > @@ -281,6 +281,13 @@ typedef struct mime_node {
> >  /* The number of children of this part. */
> >  int nchildren;
> >  
> > +/* The parent of this node or NULL if this is the root node. */
> > +const struct mime_node *parent;
> > +
> > +/* The depth-first part number of this child if the MIME tree is
> > + * being traversed in depth-first order, or -1 otherwise. */
> > +int part_num;
> > +
> >  /* True if decryption of this part 

RFC: tag macros

[David Bremner]

On Wed, 18 Jan 2012 10:50:50 -0800, Jameson Graef Rollins  wrote:
> 
> I've been wanting to put together a wiki page that lists all the useful
> functions and has examples of how to put them together into useful
> functions.
> 

If we're going to go the way of providing a toolkit/api for uses to make
their own bindings, then I think that we should make the effort to
provide a proper info document with the distribution, rather than
relying on the wiki.  Of course, that means more work, and yet another
markup language, I guess.

d

[PATCH v2 2/2] Add pseudo-compatibility with gmime 2.6

[Tomi Ollila]

On Wed, 18 Jan 2012 12:19:45 -0500, Tom Prince  
wrote:
> 
> How did you test against multiple versions? Using different machines? If
> there was a way for configure (or something to pick the version, I would
> setup the buildbot to test against both, so we don't regress either.

I currently compile notmuch on Fedora 15 so that I have 

LIBRARY_PATH=/my/own/path/to/x86_64-linux/lib
and
CPATH=/my/own/path/to/x86_64-linux/include

and gmime 2.4 development files are located in these
directories. I'll be hiding gmime 2.4 stuff from these
soon in order to build against 2.6 stuff.

Tomi

[PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Austin Clements]

Quoth Aaron Ecay on Jan 18 at  5:18 pm:
> Compile-time dependencies on ?cl? are absolutely not a problem.
> Virtually every major elisp program depends on cl at compile time.
> Runtime dependencies are not allowed in code distributed with emacs
> because of RMS?s conservativism[1].
> 
> Since notmuch isn?t distributed with emacs and has no aspirations to
> ever be, the project could decide to require cl at runtime.  Many
> elisp programs do.  (A quick grep through my .emacs.d folder turns up
> anything.el and clojure-mode as two large/?mainstream? projects that
> do, as well as at least a dozen smaller utility files.)  So many emacs
> users have cl loaded all the time when they are using emacs.  But
> unless the project (i.e. us) decides explicitly ?runtime cl is OK? (or
> perhaps ?it is not?), contributors will always go back and forth over
> using it.  To avoid patch and review churn, we ought to decide which
> of these we pick (and I vote for allowing runtime use.)

I agree with Aaron.  There's no excuse for some of the functionality
that can only be found in cl to be missing from core Emacs and it's
ridiculous to re-implement it time and again (I count at least five
obvious reimplementations of remove-if in code shipped with Emacs).
There are a lot of compelling reasons to use cl and I'm not aware of
any good technical reasons why notmuch shouldn't.

[PATCH 2/2] Silence buildbot warnings about unused results

[Austin Clements]

This ignores the results of the two writes in sigint handlers even
harder than before.

While my libc lacks the declarations that trigger these warnings, this
can be tested by adding the following to notmuch.h:

__attribute__((warn_unused_result))
ssize_t write(int fd, const void *buf, size_t count);
---
 compat/compat.h |8 
 notmuch-new.c   |6 +-
 notmuch-tag.c   |5 -
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/compat/compat.h b/compat/compat.h
index 7767fe8..b2e2736 100644
--- a/compat/compat.h
+++ b/compat/compat.h
@@ -46,6 +46,14 @@ getdelim (char **lineptr, size_t *n, int delimiter, FILE 
*fp);
 char* strcasestr(const char *haystack, const char *needle);
 #endif /* !HAVE_STRCASESTR */

+/* Silence gcc warnings about unused results.  These warnings exist
+ * for a reason; any use of this needs to be justified. */
+#ifdef __GNUC__
+#define IGNORE_RESULT(x) ({ __typeof__(x) __z = (x); (void)(__z = __z); })
+#else /* !__GNUC__ */
+#define IGNORE_RESULT(x) x
+#endif /* __GNUC__ */
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/notmuch-new.c b/notmuch-new.c
index 3512de7..a569a54 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -67,7 +67,11 @@ handle_sigint (unused (int sig))
 {
 static char msg[] = "Stopping... \n";

-(void) write(2, msg, sizeof(msg)-1);
+/* This write is "opportunistic", so it's okay to ignore the
+ * result.  It is not required for correctness, and if it does
+ * fail or produce a short write, we want to get out of the signal
+ * handler as quickly as possible, not retry it. */
+IGNORE_RESULT (write (2, msg, sizeof(msg)-1));
 interrupted = 1;
 }

diff --git a/notmuch-tag.c b/notmuch-tag.c
index 292c5da..1564182 100644
--- a/notmuch-tag.c
+++ b/notmuch-tag.c
@@ -26,7 +26,10 @@ static void
 handle_sigint (unused (int sig))
 {
 static char msg[] = "Stopping... \n";
-(void) write(2, msg, sizeof(msg)-1);
+
+/* See handle_sigint in notmuch-new.c for the justification for
+ * ignoring write's result. */
+IGNORE_RESULT (write (2, msg, sizeof(msg)-1));
 interrupted = 1;
 }

-- 
1.7.7.3

[PATCH 1/2] show: Handle read and write errors

[Austin Clements]

For showing a message in raw format, rather than silently succeeding
when a read or a write fails (or, probably, looping if a read fails),
try to print an error message and exit with a non-zero status.

This silences one of the buildbot warnings about unused resuls.  While
my libc lacks the declarations that trigger these warnings, this can
be tested by adding the following to notmuch.h:

__attribute__((warn_unused_result))
size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream);
---
 notmuch-show.c |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/notmuch-show.c b/notmuch-show.c
index d14dac9..c674e25 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -883,7 +883,17 @@ do_show_single (void *ctx,

while (!feof (file)) {
size = fread (buf, 1, sizeof (buf), file);
-   (void) fwrite (buf, size, 1, stdout);
+   if (ferror (file)) {
+   fprintf (stderr, "Error: Read failed from %s\n", filename);
+   fclose (file);
+   return 1;
+   }
+
+   if (fwrite (buf, size, 1, stdout) != 1) {
+   fprintf (stderr, "Error: Write failed\n");
+   fclose (file);
+   return 1;
+   }
}

fclose (file);
-- 
1.7.7.3

[PATCH 0/2] Fix or silence "unused result" warnings

[Austin Clements]

I'm afraid I bikeshedded dme's original patch for this into oblivion
(id:"1324503532-5799-1-git-send-email-dme at dme.org") and we still have
these warnings on the buildbot.  Tomi convinced me that dme was right
and I was wrong, so I'm bringing dme's patch back.

The first patch actually fixes the warning, since the code in show was
wantonly ignoring errors that could have correctness implications.
This write didn't get much attention in the original thread.

The second is a rework of dme's patch to silence the warning for the
remaining writes.  I cleaned up the formatting, simplified the macro
magic a little, and added a comment justifying its use.

[PATCH v2] emacs: Make the part content available to the mm-inline* checks.

[David Edmondson]

On Wed, 18 Jan 2012 22:04:36 +0400, Dmitry Kurochkin  wrote:
> On Wed, 18 Jan 2012 17:39:31 +, David Edmondson  wrote:
> > The `mm-inlinable-p' and `mm-inlined-p' functions work better if they
> > have access to the data of the relevant part, so load that content
> > before calling either function.
> > 
> > This fixes the display of attached image/jpeg parts, for example.
> 
> Not so long ago I made an opposite change to avoid fetching useless
> parts (e.g. audio files).  Looks like we need a better check here.  Can
> we know from Content-Type if fetching a part body would be useful?

What if `notmuch-show-insert-part-*/*' consulted a list of content-type
regexps to attempt to inline?

That would allow a sane default (("image/*" "text/*") perhaps), but also
allow more to be added to that list (or some to be removed), either by
code that detected the (in)ability to render it or the user.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/b76617b5/attachment.pgp>

[PATCH 2/3] emacs: use a single history for all searches

[David Edmondson]

On Wed, 18 Jan 2012 21:57:27 +0400, Dmitry Kurochkin  wrote:
> > The test output updates included here should be with the previous patch,
> > shouldn't they?
> 
> Indeed.  Would send v2.

That's not necessary for me.

> > Should user-typed queries be trimmed?
> 
> IMO that would not hurt.  But we need to do it before it gets added to
> the history.  And that may be tricky.  So this patch does trimming only
> for queries from notmuch-hello search box (as it was before).

Okay.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/44801b31/attachment.pgp>

RFC: tag macros

[Jameson Graef Rollins]

On Wed, 18 Jan 2012 20:04:44 -0400, David Bremner  wrote:
> If we're going to go the way of providing a toolkit/api for uses to make
> their own bindings, then I think that we should make the effort to
> provide a proper info document with the distribution, rather than
> relying on the wiki.  Of course, that means more work, and yet another
> markup language, I guess.

Can't we just use the emacs build-in documentation?

My idea of documenting on the wiki was just as a starting point.  It
could list some of the available functions, and how to use them, and
then have good references to emacs documentation and how to find it.

I'm guessing we also have a lot of functions that are marked interactive
that don't necessarily need to be.  Weeding those out might make
documentation easier.

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/20120118/efb4ea57/attachment-0001.pgp>

[PATCH v2] emacs: Make the part content available to the mm-inline* checks.

[David Edmondson]

The `mm-inlinable-p' and `mm-inlined-p' functions work better if they
have access to the data of the relevant part, so load that content
before calling either function.

This fixes the display of attached image/jpeg parts, for example.
---

Removed the cruft that crept into the previous patch.

 emacs/notmuch-show.el |   14 ++
 1 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 2df8d3b..f280df2 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -330,14 +330,12 @@ current buffer, if possible."
 (with-temp-buffer
   (let* ((charset (plist-get part :content-charset))
 (handle (mm-make-handle (current-buffer) `(,content-type (charset 
. ,charset)
-   (if (and (mm-inlinable-p handle)
-(mm-inlined-p handle))
-   (let ((content (notmuch-show-get-bodypart-content msg part nth)))
- (insert content)
- (set-buffer display-buffer)
- (mm-display-part handle)
- t)
- nil)
+   (insert (notmuch-show-get-bodypart-content msg part nth))
+   (when (and (mm-inlinable-p handle)
+  (mm-inlined-p handle))
+ (set-buffer display-buffer)
+ (mm-display-part handle)
+ t)

 (defvar notmuch-show-multipart/alternative-discouraged
   '(
-- 
1.7.8.3

[PATCH] Fix dependency generation for compat, test, and util

[Tomi Ollila]

On Sun, 15 Jan 2012 15:20:42 -0500, Austin Clements  wrote:
> This adds source files in compat, test, and util to SRCS so that the
> top-level Makefile.local will generate dependency files for them.
> ---

+1

[PATCH] Fix dependency generation for CLI sources

[Tomi Ollila]

On Sun, 15 Jan 2012 15:20:23 -0500, Austin Clements  wrote:
> Previously, the dependency file list was generated before the CLI
> sources were added to SRCS, so dependency files weren't generated for
> CLI sources.  This moves that code to after the CLI sources are added.
> ---

+1

[PATCH] emacs: Make the part content available to the mm-inline* checks.

[David Edmondson]

On Wed, 18 Jan 2012 17:33:13 +, David Edmondson  wrote:
> +   ;; Nonsense required to have the new gnus `shr' HTML
> +   ;; display code work.
> +   (let ((gnus-inhibit-images nil))
> + (makunbound 'gnus-summary-buffer) ; Blech.
> + (mm-display-part handle))
> +   t)

Bleugh. Sorry, don't apply this patch. I'll produce a clean one.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/40eedf9f/attachment.pgp>

[PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Aaron Ecay]

On Wed, 18 Jan 2012 14:48:02 +0100, Pieter Praet  wrote:
> My original intent of conserving a key(chord) [1] (which in
> retrospect was a fairly pointless exercise in and of itself
> [2,3]) seems to have inconspicuously morphed into an equally
> questionable crusade [4] against the `cl' package.
> 
> As long there's other functions in Notmuch depending on
> compile-time `cl', there's really no incentive whatsoever
> to replace your perfectly fine solution.

(This is not strictly related to the immediate issue of these patches,
but now seems as good a time as any to discuss it.)

Compile-time dependencies on ?cl? are absolutely not a problem.
Virtually every major elisp program depends on cl at compile time.
Runtime dependencies are not allowed in code distributed with emacs
because of RMS?s conservativism[1].

Since notmuch isn?t distributed with emacs and has no aspirations to
ever be, the project could decide to require cl at runtime.  Many
elisp programs do.  (A quick grep through my .emacs.d folder turns up
anything.el and clojure-mode as two large/?mainstream? projects that
do, as well as at least a dozen smaller utility files.)  So many emacs
users have cl loaded all the time when they are using emacs.  But
unless the project (i.e. us) decides explicitly ?runtime cl is OK? (or
perhaps ?it is not?), contributors will always go back and forth over
using it.  To avoid patch and review churn, we ought to decide which
of these we pick (and I vote for allowing runtime use.)

Aaron

Footnotes:
[1] He specifically objects to the way that the cl package uses keyword
arguments, calling it un-Elisp-like.  He has resisted past efforts
to merge cl functions into Elisp core, although they are slowly
diffusing across the barrier.

-- 
Aaron Ecay

[PATCH v2] emacs: add invisible dot instead of space at the end of notmuch-hello search box

[Tomi Ollila]

On Tue, 17 Jan 2012 19:55:34 +0400, Dmitry Kurochkin  wrote:
> This makes `show-trailing-whitespace' happy, i.e. it does not mark the
> whole search box line as trailing spaces.
> 
> Since the dot is invisible, this change makes no visible difference
> for `notmuch-hello'.
> ---

+1

[PATCH 2/3] test: Add `test_emacs_expect_t'.

[Tomi Ollila]

On Tue, 17 Jan 2012 14:07:03 +, David Edmondson  wrote:
> Add a new test function to allow simpler testing of emacs
> functionality.
> 
> `test_emacs_expect_t' takes one argument - a list expression to
> evaluate. The test passes if the expression returns `t', otherwise it
> fails and the output is reported to the tester.
> ---
> 
> Re-worked as Dmitry suggested.
> 
> diff --git a/test/test-lib.sh b/test/test-lib.sh
> index 7c9ce24..4b05760 100644
> --- a/test/test-lib.sh
> +++ b/test/test-lib.sh
> @@ -503,6 +503,39 @@ test_expect_equal_file ()
>  fi
>  }
>  
> +test_emacs_expect_t () {
> + test "$#" = 1 || error "bug in the test script: not 1 parameter to 
> test_emacs_expect_t"
> +
> + # Run the test.
> + if ! test_skip "$test_subtest_name"
> + then
> + # We cannot call 'test_emacs' in a subshell, because
> + # the setting of EMACS_SERVER would not persist
> + # throughout a sequence of tests, so we use a
> + # temporary file.
> + tmp="$TMPDIR"; if [ -z "$tmp" ]; then tmp=/tmp; fi
> + output="$tmp/test_emacs_output.$$"
> + test_emacs "$1" > "${output}"
> + result=$(cat "${output}")
> + rm -f "${output}"
> + fi
> +
> + # Restore state after the test.
> + exec 1>&6 2>&7  # Restore stdout and stderr
> + inside_subtest=
> +
> + # Report success/failure.
> + if ! test_skip "$test_subtest_name"
> + then
> + if [ "$result" == t ]

if [ "$result" = t ]

to be compatible with POSIX and consistent with rest code.

> + then
> + test_ok_ "$test_subtest_name"
> + else
> + test_failure_ "$test_subtest_name" "$(eval printf 
> ${result})"

This added 'eval' made me investigate further... running 

emacsclient --eval '(print (concat "a" "b" "\t" "c" "\n" "z"))'

outputs "ab c\nz" (tab between 'ab' and 'c', quotes (") around
the whole output and newlines as "\n" (even '\r' is converted)).

If emacs tests run via test_emacs_expect_t wrote their output 
to ${output} directly above code could be much cleaner in many
places. Environment variable could be used for the file name.

Tomi

[PATCH v2 4/5] emacs: Use the new JSON reply format.

[David Edmondson]

On Wed, 18 Jan 2012 09:32:34 -0700, Adam Wolfe Gordon <awg+notmuch at xvx.ca> 
wrote:
> Using the new JSON reply format allows emacs to quote HTML
> parts nicely by using mm-display-part to turn them into displayable
> text, then quoting them. This is very useful for users who
> regularly receive HTML-only email.
> 
> The behavior for messages that contain plain text parts should be
> unchanged.

I think that this looks pretty good now. We should get some experience
of using it.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/0b4bb8a7/attachment.pgp>

[PATCH v2 2/4] reply: Add a JSON reply format.

[Adam Wolfe Gordon]

On Wed, Jan 18, 2012 at 16:07, Jani Nikula  wrote:
> I know I asked you to adhere to notmuch coding style like above, but I
> meant in the context of your patch, not elsewhere. Cleanups like this
> should really be separate patches. Sorry if I was ambiguous.

Oops - my bad.  I assumed I had introduced all the spacing problems in
the file and blindly fixed them.

[PATCH] News for tag exclusion

[Austin Clements]

---
 NEWS |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index 1e561a9..6afa912 100644
--- a/NEWS
+++ b/NEWS
@@ -11,6 +11,13 @@ Reply to sender
   to all. The feature is available through the new command line option
   --reply-to=(all|sender).

+Tag exclusion
+
+  Tags can be automatically excluded from search results unless they
+  appear explicitly in a query.  By default, notmuch excludes the tags
+  deleted and spam.  This can be changed using the new config setting
+  search.auto_exclude_tags.
+
 Emacs Interface
 ---

@@ -21,6 +28,14 @@ Reply to sender
   and search modes, 'r' has been bound to reply to sender, replacing
   reply to all, which now has key binding 'R'.

+Library changes
+---
+
+New functions
+
+  notmuch_query_add_tag_exclude supports the new tag exclusion
+  feature.
+
 Notmuch 0.11 (2012-01-13)
 =

-- 
1.7.7.3

[PATCH] config: Better formatting for search section comment

[Austin Clements]

Since "auto_exclude_tags" is long and its description is multi-line,
start the description on the next line and indent it consistently.
---
 notmuch-config.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/notmuch-config.c b/notmuch-config.c
index 3d4d5b9..8dcfe86 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -89,9 +89,10 @@ static const char search_config_comment[] =
 "\n"
 " The following option is supported here:\n"
 "\n"
-"\tauto_exclude_tags  A ;-separated list of tags that will be\n"
-"\t excluded from search results by default.  Using an excluded tag\n"
-"\t in a query will override that exclusion.\n";
+"\tauto_exclude_tags\n"
+"\t\tA ;-separated list of tags that will be excluded from\n"
+"\t\tsearch results by default.  Using an excluded tag in a\n"
+"\t\tquery will override that exclusion.\n";

 struct _notmuch_config {
 char *filename;
-- 
1.7.7.3

[PATCH] test: always report missing prereqs, independent of `--verbose' option

[Tomi Ollila]

On Wed, 18 Jan 2012 13:19:41 +0100, Pieter Praet  wrote:
> When tests are skipped due to missing prereqs, those prereqs are only
> displayed when running with the `--verbose' option.  This is essential
> information when troubleshooting, so always send to stdout.
> 
> ---

Instead of this the test suite could be enchanged so that
full log of the execution is stored somewhere and path
to that file is displayed at the end of test. Generally,
all output could stay available after tests exit so that
those could be investigated furtner.

(I tried to grep 'missing prerequisites' after running test
but did not find the info. the file opened for >&3 has been
deleted already?)

Now I just see huge amounts of missing prerequisites: emacs(1)
in my output (I presume that doesn't happen due to my
hack to "hide" emacs).

But well, I'm not against applying this patch -- just that
the test system starts to get so rotten touching it gives
shivers...

Tomi

> 
>  test/test-lib.sh |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/test/test-lib.sh b/test/test-lib.sh
> index d1fbc05..6560628 100644
> --- a/test/test-lib.sh
> +++ b/test/test-lib.sh
> @@ -673,8 +673,8 @@ test_skip () {
>  
>  test_check_missing_external_prereqs_ () {
>   if test -n "$test_subtest_missing_external_prereqs_"; then
> - say_color skip >&3 "missing prerequisites:"
> - echo "$test_subtest_missing_external_prereqs_" >&3
> + say_color skip >&1 "missing prerequisites:"
> + echo "$test_subtest_missing_external_prereqs_" >&1
>   test_report_skip_ "$@"
>   else
>   false
> -- 
> 1.7.8.1

[PATCH 0/3] Second step of 'show' rewrite

[Austin Clements]

Quoth Dmitry Kurochkin on Jan 19 at 12:35 am:
> Hi Austin.
> 
> On Wed, 18 Jan 2012 15:28:24 -0500, Austin Clements  
> wrote:
> > This adds support for self-recursive message formatters, while
> > maintaining backwards compatibility with old style formatters.  After
> > this, each format can be converted to the new style individually and,
> > once they're all converted, a bunch of code can be deleted.
> > 
> > These three patches are independent and can be pushed in any order.  I
> > put them in a series because pushing them before any formatter
> > rewrites will simplify dependencies between the individual formatter
> > rewrites.
> > 
> 
> Thank you for the patches.  Sorry, I did not manage to review your
> previous RFC series [1] yet (but it is on my TODO list).  These patches
> are partially the same as in the RFC series.  I suppose I should start
> with reviewing these new series first, right?  Does it still makes sense
> to review the RFC series after that?

No worries.  Reviewing these first would be best.  These patches are
very similar to the first few in the RFC series (maybe identical?  I
forget), so there's no point in reviewing those after these.  However,
the RFC series goes on to restructure the text formatter and I would
love to have someone skim over those before I send that part out for
real.

> Regards,
>   Dmitry
> 
> [1] id:"1326332973-30225-1-git-send-email-amdragon at mit.edu"

[PATCH 3/3] show: Introduce mime_node formatter callback

[Austin Clements]

This callback is the gateway to the new mime_node_t-based formatters.
This maintains backwards compatibility so the formatters can be
transitioned one at a time.  Once all formatters are converted, the
formatter structure can be reduced to only message_set_{start,sep,end}
and part, most of show_message can be deleted, and all of
show-message.c can be deleted.
---
 notmuch-client.h |6 ++
 notmuch-reply.c  |2 +-
 notmuch-show.c   |   22 ++
 3 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/notmuch-client.h b/notmuch-client.h
index b3dcb6b..3ccdfad 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -54,8 +54,14 @@
 #define STRINGIFY(s) STRINGIFY_(s)
 #define STRINGIFY_(s) #s

+struct mime_node;
+struct notmuch_show_params;
+
 typedef struct notmuch_show_format {
 const char *message_set_start;
+void (*part) (const void *ctx,
+ struct mime_node *node, int indent,
+ struct notmuch_show_params *params);
 const char *message_start;
 void (*message) (const void *ctx,
 notmuch_message_t *message,
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 0f682db..9a224e2 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -31,7 +31,7 @@ static void
 reply_part_content (GMimeObject *part);

 static const notmuch_show_format_t format_reply = {
-"",
+"", NULL,
"", NULL,
"", NULL, reply_headers_message_part, ">\n",
"",
diff --git a/notmuch-show.c b/notmuch-show.c
index ecadfa8..46eef44 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -42,7 +42,7 @@ static void
 format_part_end_text (GMimeObject *part);

 static const notmuch_show_format_t format_text = {
-"",
+"", NULL,
"\fmessage{ ", format_message_text,
"\fheader{\n", format_headers_text, 
format_headers_message_part_text, "\fheader}\n",
"\fbody{\n",
@@ -85,7 +85,7 @@ static void
 format_part_end_json (GMimeObject *part);

 static const notmuch_show_format_t format_json = {
-"[",
+"[", NULL,
"{", format_message_json,
"\"headers\": {", format_headers_json, 
format_headers_message_part_json, "}",
", \"body\": [",
@@ -106,7 +106,7 @@ format_message_mbox (const void *ctx,
 unused (int indent));

 static const notmuch_show_format_t format_mbox = {
-"",
+"", NULL,
 "", format_message_mbox,
 "", NULL, NULL, "",
 "",
@@ -125,7 +125,7 @@ static void
 format_part_content_raw (GMimeObject *part);

 static const notmuch_show_format_t format_raw = {
-"",
+"", NULL,
"", NULL,
"", NULL, format_headers_message_part_text, "\n",
 "",
@@ -762,6 +762,20 @@ show_message (void *ctx,
  int indent,
  notmuch_show_params_t *params)
 {
+if (format->part) {
+   void *local = talloc_new (ctx);
+   mime_node_t *root, *part;
+
+   if (mime_node_open (local, message, params->cryptoctx, params->decrypt,
+   ) != NOTMUCH_STATUS_SUCCESS)
+   return;
+   part = mime_node_seek_dfs (root, params->part < 0 ? 0 : params->part);
+   if (part)
+   format->part (local, part, indent, params);
+   talloc_free (local);
+   return;
+}
+
 if (params->part <= 0) {
fputs (format->message_start, stdout);
if (format->message)
-- 
1.7.7.3

[PATCH 2/3] show: Use consistent header ordering in the text format

[Austin Clements]

Previously, top-level message headers were printed as Subject, From,
To, Date, while embedded message headers were printed From, To,
Subject, Date.  This makes both cases use the former order and updates
the tests accordingly.

Strangely, the raw format also uses this function, so this also fixes
the two raw format tests affected by this change.
---
 notmuch-show.c |2 +-
 test/multipart |   12 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/notmuch-show.c b/notmuch-show.c
index d14dac9..ecadfa8 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -360,6 +360,7 @@ format_headers_message_part_text (GMimeMessage *message)
 InternetAddressList *recipients;
 const char *recipients_string;

+printf ("Subject: %s\n", g_mime_message_get_subject (message));
 printf ("From: %s\n", g_mime_message_get_sender (message));
 recipients = g_mime_message_get_recipients (message, 
GMIME_RECIPIENT_TYPE_TO);
 recipients_string = internet_address_list_to_string (recipients, 0);
@@ -371,7 +372,6 @@ format_headers_message_part_text (GMimeMessage *message)
 if (recipients_string)
printf ("Cc: %s\n",
recipients_string);
-printf ("Subject: %s\n", g_mime_message_get_subject (message));
 printf ("Date: %s\n", g_mime_message_get_date_as_string (message));
 }

diff --git a/test/multipart b/test/multipart
index f83526b..2dd73f5 100755
--- a/test/multipart
+++ b/test/multipart
@@ -121,9 +121,9 @@ Date: Fri, 05 Jan 2001 15:43:57 +
 part{ ID: 2, Content-type: multipart/mixed
 part{ ID: 3, Content-type: message/rfc822
 header{
+Subject: html message
 From: Carl Worth 
 To: cworth at cworth.org
-Subject: html message
 Date: Fri, 05 Jan 2001 15:42:57 +
 header}
 body{
@@ -162,9 +162,9 @@ cat OU
 cat OUT
 # output should *not* include newline
 echo >>OUTPUT
 cat OUTPUT
 cat 

[PATCH 1/3] mime node: Record depth-first part numbers

[Austin Clements]

This makes the part numbers readily accessible to formatters.
Hierarchical part numbering would be a more natural and efficient fit
for MIME and may be the way to go in the future, but depth-first
numbering maintains compatibility with what we currently do.
---
 mime-node.c  |   33 -
 notmuch-client.h |   11 +++
 2 files changed, 43 insertions(+), 1 deletions(-)

diff --git a/mime-node.c b/mime-node.c
index d26bb44..30b542f 100644
--- a/mime-node.c
+++ b/mime-node.c
@@ -104,6 +104,10 @@ mime_node_open (const void *ctx, notmuch_message_t 
*message,
 root->nchildren = 1;
 root->ctx = mctx;

+root->part_num = 0;
+root->next_child = 0;
+root->next_part_num = 1;
+
 *root_out = root;
 return NOTMUCH_STATUS_SUCCESS;

@@ -133,6 +137,8 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
talloc_free (node);
return NULL;
 }
+node->parent = parent;
+node->part_num = node->next_part_num = -1;

 /* Deal with the different types of parts */
 if (GMIME_IS_PART (part)) {
@@ -217,6 +223,7 @@ mime_node_t *
 mime_node_child (const mime_node_t *parent, int child)
 {
 GMimeObject *sub;
+mime_node_t *node;

 if (!parent || child < 0 || child >= parent->nchildren)
return NULL;
@@ -234,7 +241,31 @@ mime_node_child (const mime_node_t *parent, int child)
INTERNAL_ERROR ("Unexpected GMimeObject type: %s",
g_type_name (G_OBJECT_TYPE (parent->part)));
 }
-return _mime_node_create (parent, sub);
+node = _mime_node_create (parent, sub);
+
+if (child == parent->next_child && parent->next_part_num != -1) {
+   /* We're traversing in depth-first order.  Record the child's
+* depth-first numbering. */
+   node->part_num = parent->next_part_num;
+   node->next_part_num = node->part_num + 1;
+
+   /* Drop the const qualifier because these are internal fields
+* whose mutability doesn't affect the interface. */
+   ((mime_node_t*)parent)->next_child++;
+   ((mime_node_t*)parent)->next_part_num = -1;
+
+   if (node->nchildren == 0) {
+   /* We've reached a leaf, so find the parent that has more
+* children and set it up to number its next child. */
+   const mime_node_t *it = node;
+   while (it && it->next_child == it->nchildren)
+   it = it->parent;
+   if (it)
+   ((mime_node_t*)it)->next_part_num = node->part_num + 1;
+   }
+}
+
+return node;
 }

 static mime_node_t *
diff --git a/notmuch-client.h b/notmuch-client.h
index 62ede28..b3dcb6b 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -281,6 +281,13 @@ typedef struct mime_node {
 /* The number of children of this part. */
 int nchildren;

+/* The parent of this node or NULL if this is the root node. */
+const struct mime_node *parent;
+
+/* The depth-first part number of this child if the MIME tree is
+ * being traversed in depth-first order, or -1 otherwise. */
+int part_num;
+
 /* True if decryption of this part was attempted. */
 notmuch_bool_t decrypt_attempted;
 /* True if decryption of this part's child succeeded.  In this
@@ -302,6 +309,10 @@ typedef struct mime_node {
 /* Internal: For successfully decrypted multipart parts, the
  * decrypted part to substitute for the second child. */
 GMimeObject *decrypted_child;
+
+/* Internal: The next child for depth-first traversal and the part
+ * number to assign it (or -1 if unknown). */
+int next_child, next_part_num;
 } mime_node_t;

 /* Construct a new MIME node pointing to the root message part of
-- 
1.7.7.3

[PATCH 0/3] Second step of 'show' rewrite

[Austin Clements]

This adds support for self-recursive message formatters, while
maintaining backwards compatibility with old style formatters.  After
this, each format can be converted to the new style individually and,
once they're all converted, a bunch of code can be deleted.

These three patches are independent and can be pushed in any order.  I
put them in a series because pushing them before any formatter
rewrites will simplify dependencies between the individual formatter
rewrites.

RFC: tag macros

[David Edmondson]

On Wed, 18 Jan 2012 10:45:06 -0400, David Bremner  wrote:
> Here is a very early stage proposal to provide tagging macros for
> notmuch show mode. 

Nice idea. Please make it work on regions as well.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/345db38f/attachment.pgp>

RFC: tag macros

[David Bremner]

On Wed, 18 Jan 2012 13:33:04 -0500, Austin Clements  wrote:
> Quoth David Bremner on Jan 18 at 10:45 am:

> What about simply providing an API that takes a bunch of tag
> operations and applies them to the current thread/message/region?

My main motivation here is (as you can probably see from the example)
dealing with patches, and in that setting, tagging the whole thread is
is almost never what you want.

That aside, thread tagging is already there in search view, and I guess
could be done by selecting the whole thread and tagging that region.

I haven't really looked at how to apply tags to regions in
notmuch-show-mode. Is there code around that does that? Or more
generally iterate over messages in a region?

d

[PATCH v2] emacs: add invisible dot instead of space at the end of notmuch-hello search box

[Pieter Praet]

On Tue, 17 Jan 2012 19:55:34 +0400, Dmitry Kurochkin  wrote:
> This makes `show-trailing-whitespace' happy, i.e. it does not mark the
> whole search box line as trailing spaces.
> 
> Since the dot is invisible, this change makes no visible difference
> for `notmuch-hello'.
> ---
>  emacs/notmuch-hello.el |9 ++---
>  1 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
> index 02017ce..38846ef 100644
> --- a/emacs/notmuch-hello.el
> +++ b/emacs/notmuch-hello.el
> @@ -508,9 +508,12 @@ Complete list of currently available key bindings:
>  (length "Search: ")))
>  :action (lambda (widget  ignore)
>(notmuch-hello-search (widget-value widget
> - ;; add an invisible space to make `widget-end-of-line' ignore
> - ;; trailine spaces in the search widget field
> - (widget-insert " ")
> + ;; Add an invisible dot to make `widget-end-of-line' ignore
> + ;; trailing spaces in the search widget field.  A dot is used
> + ;; instead of a space to make `show-trailing-whitespace'
> + ;; happy, i.e. avoid it marking the whole line as trailing
> + ;; spaces.
> + (widget-insert ".")
>   (put-text-property (1- (point)) (point) 'invisible t)
>   (widget-insert "\n")
>  
> -- 
> 1.7.8.3
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

+1


Peace

-- 
Pieter

[PATCH] emacs: Truncate lines and do not enable visual-line-mode in notmuch-show buffers.

[Pieter Praet]

On Mon, 16 Jan 2012 14:13:22 +, David Edmondson  wrote:
> Enable the truncation of lines in `notmuch-show-mode' to avoid visual
> noise caused by the wrapping of the header lines.
> 
> Don't enable `visual-line-mode' because it disables line truncation.
> 
> The benefits of `visual-line-mode' were that it wrapped long lines
> in received messages. With `notmuch-wash-wrap-long-lines' now default
> behaviour, this is no longer required.
> ---
>  emacs/notmuch-show.el |6 ++
>  1 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 1a250a3..797f94b 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -873,9 +873,6 @@ buffer."
>  
>(jit-lock-register #'notmuch-show-buttonise-links)
>  
> -  ;; Act on visual lines rather than logical lines.
> -  (visual-line-mode t)
> -
>(run-hooks 'notmuch-show-hook))
>  
>  ;; Move straight to the first open message
> @@ -987,7 +984,8 @@ All currently available key bindings:
>(use-local-map notmuch-show-mode-map)
>(setq major-mode 'notmuch-show-mode
>   mode-name "notmuch-show")
> -  (setq buffer-read-only t))
> +  (setq buffer-read-only t
> + truncate-lines t))
>  
>  (defun notmuch-show-move-to-message-top ()
>(goto-char (notmuch-show-message-top)))
> -- 
> 1.7.7.3
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

+1


Peace

-- 
Pieter

[feature request] thread-based queries

[Patrick Totzke]

Hi everyone,

A recent discussion on alot's issue tracker[0]  made it clear that it might be 
useful to have a thread-based
matching for queries as an alternative to the current message based approach:

Consider a thread with two messages, one has a single tag 'flagged', the other 
a single tag 'unread'.
Now the thread doesn't match "tag:flagged AND tag:unread" as it doesn't contain 
any matching messages.
However, listing the tags of this thread accumulates to ['flagged', 'unread'].

As far as I know, there is no way one can tell notmuch to evaluate the query 
with threads as atomic entities
instead of messages so that the thread in the example above matches. I would 
like to see such a switch in 
libnotmuch and the python bindings, maybe as parameter to 
`notmuch_query_create` or as something similar to 
`notmuch_query_set_sort`.

I am aware that I can simulate the intended behaviour by rewriting the query 
myself, but I think
such a feature makes sense not only for alot users and should be implemented at 
a lower level.
Moreover, I wouldn't be surprised if doing this at a library level is less 
painful than higher up
as Xapian has to parse query formulae anyway and hence should offer some 
convenience methods for dealing with them.
Please correct me if I'm wrong here or have just overlooked previous 
discussions/solutions for this issue.

Best,
/p

[o]: https://github.com/pazz/alot/issues/270

[PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Pieter Praet]

On Wed, 18 Jan 2012 13:03:06 +, David Edmondson  wrote:
> Hey, look - I deliberately pressed 'r' instead of 'R'!
> 

You have remarkably malleable muscle memory.

Care to donate some to the less fortunate ? :)

> On Wed, 18 Jan 2012 12:57:53 +, David Edmondson  wrote:
> > On Wed, 18 Jan 2012 13:15:55 +0100, Pieter Praet  
> > wrote:
> > > On Wed, 18 Jan 2012 10:13:35 +, David Edmondson  
> > > wrote:
> > > > On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet  
> > > > wrote:
> > > > > > [...] What's wrong with '(loop ... collect ...)'?
> > > > > 
> > > > > Nothing at all.  I was fixing my own patch [1] without resorting to
> > > > > requiring the `cl' package at runtime :)  Would be nice if we could
> > > > > get rid of the compile-time dependency as well, though.
> > > > 
> > > > Can you explain why it's necessary at runtime?
> > > 
> > > Because otherwise `remove-if-not' and `member-if-not' would
> > > be void, as you alluded to previously [1,2].
> > 
> > Ah, not macros. Sorry for being slow.
> 
> But, loop is a macro, so the loop collector variant (which I originally
> suggested) would be fine with just loading cl during compilation.

Absolutely.

My original intent of conserving a key(chord) [1] (which in
retrospect was a fairly pointless exercise in and of itself
[2,3]) seems to have inconspicuously morphed into an equally
questionable crusade [4] against the `cl' package.

As long there's other functions in Notmuch depending on
compile-time `cl', there's really no incentive whatsoever
to replace your perfectly fine solution.

So as said [5], feel free to disregard it, just bikesheddin'...


All of my patches in this thread belong in notmuch::obsolete.


Peace

-- 
Pieter

[1] id:"1326710551-23122-1-git-send-email-pieter at praet.org"
[2] id:"87wr8rc2ex.fsf at praet.org"
[3] id:"87ehuzl5fg.fsf at nikula.org"
[4] id:"87r4yza95m.fsf at praet.org"
[5] id:"87fwfd8h0i.fsf at praet.org"

compressing header lines - quick prototype

[David Edmondson]

Here's something that I was playing with this morning. It's not
finished, but has some nasty corners, so I'd like to solicit opinion on
whether it's worth finishing.

When faced with a long thread where most of the messages are closed, it
might be convenient to hide large stretches of closed headers. This code
attempts to do that.

You can run `dme/notmuch-show-compress-headers' manually in a
`notmuch-show-mode' buffer or (for the terminally brave) attach the same
function to `notmuch-show-hook'.

There are still problems with the nested invisibility specs and the
current `notmuch-show-advance-and-archive' and friends get confused, but
it should be enough for you to get the idea.

After using it for a bit I came to the conclusion that it's not worth
pursuing, but figured that I'd post it to get feedback from others.

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/emacs-lisp
Size: 2112 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/846e14cc/attachment.bin>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/846e14cc/attachment.pgp>

[PATCH v2] emacs: Make the part content available to the mm-inline* checks.

[Austin Clements]

Quoth Dmitry Kurochkin on Jan 18 at 11:00 pm:
> On Wed, 18 Jan 2012 18:30:36 +, David Edmondson  wrote:
> > On Wed, 18 Jan 2012 22:04:36 +0400, Dmitry Kurochkin  > gmail.com> wrote:
> > > On Wed, 18 Jan 2012 17:39:31 +, David Edmondson  
> > > wrote:
> > > > The `mm-inlinable-p' and `mm-inlined-p' functions work better if they
> > > > have access to the data of the relevant part, so load that content
> > > > before calling either function.
> > > > 
> > > > This fixes the display of attached image/jpeg parts, for example.
> > > 
> > > Not so long ago I made an opposite change to avoid fetching useless
> > > parts (e.g. audio files).  Looks like we need a better check here.  Can
> > > we know from Content-Type if fetching a part body would be useful?
> > 
> > What if `notmuch-show-insert-part-*/*' consulted a list of content-type
> > regexps to attempt to inline?
> > 
> > That would allow a sane default (("image/*" "text/*") perhaps), but also
> > allow more to be added to that list (or some to be removed), either by
> > code that detected the (in)ability to render it or the user.
> 
> Perhaps there is such a list in mm already?

Shouldn't we only be doing this for parts with inline (or not
attachment) content-disposition?  That's cheap to check.  Or do we
actually want things like image attachments to get inlined, despite
their disposition?

[PATCH] config: Better formatting for search section comment

[Jameson Graef Rollins]

On Wed, 18 Jan 2012 15:56:45 -0500, Austin Clements  wrote:
> Since "auto_exclude_tags" is long and its description is multi-line,
> start the description on the next line and indent it consistently.

lgtm.
-- 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/20120118/a83eafa3/attachment.pgp>

[PATCH v3] Make buttons for attachments allow viewing as well as saving

[Austin Clements]

Quoth Mark Walters on Jan 18 at 10:46 am:
> 
> > > +(defun notmuch-show-view-part (message-id nth  filename 
> > > content-type )
> > > +  (notmuch-with-temp-part-buffer message-id nth
> > > +;; set mm-inlined-types to nil to force an external viewer
> > > +(let ((handle (mm-make-handle (current-buffer) (list content-type)))
> > > + (mm-inlined-types nil))
> > > +  ;; We override mm-save-part as notmuch-show-save-part is better
> > > +  ;; since it offers the filename
> > > +  (flet ((mm-save-part ( args) (ignore)))
> > > +   (or (mm-display-part handle)
> > > +   (notmuch-show-save-part message-id nth filename 
> > > content-type))
> > > 
> > > Is that a reasonable solution? 
> > 
> > It's *probably* safe to depend on the result of mm-display-part, but
> > you can avoid the question altogether by simply calling
> > notmuch-show-save-part from your flet mm-save-part.  E.g.,
> > 
> > (flet ((mm-save-part ( args) (notmuch-show-save-part 
> >message-id nth filename content-type)))
> >   (mm-display-part handle))
> 
> Unfortunately that does not work since mm-display-part has a local
> variable "filename".  I could copy the variables to some notmuch
> prefixed variables but maybe there is some obvious "quoting" to avoid
> the problem? (I can't easily check now as the gnu site is closed for the
> day.)

Arrrg, dynamic scoping.  Well, you can

;; Lexically bind everything we need in mm-save-part to prevent
;; potential dynamic shadowing.
(lexical-let ((message-id message-id)
  (nth nth)
  (filename filename)
  (content-type content-type))
  (flet ((mm-save-part ( args) (notmuch-show-save-part 
 message-id nth filename content-type)))
(mm-display-part handle)))

Or you could just, y'know, do what were doing.

RFC: tag macros

[Austin Clements]

Quoth David Bremner on Jan 18 at  3:03 pm:
> On Wed, 18 Jan 2012 13:33:04 -0500, Austin Clements  
> wrote:
> > Quoth David Bremner on Jan 18 at 10:45 am:
> 
> > What about simply providing an API that takes a bunch of tag
> > operations and applies them to the current thread/message/region?
> 
> My main motivation here is (as you can probably see from the example)
> dealing with patches, and in that setting, tagging the whole thread is
> is almost never what you want.
> 
> That aside, thread tagging is already there in search view, and I guess
> could be done by selecting the whole thread and tagging that region.
> 
> I haven't really looked at how to apply tags to regions in
> notmuch-show-mode. Is there code around that does that? Or more
> generally iterate over messages in a region?

Sorry, that was all a bit of a red herring in my email.  The
high-level point I was trying to make is really what Jamie said.

[PATCH 3/3 v3] emacs: colorize buttonized 'id:' links depending on the target message's state

[Pieter Praet]

* emacs/notmuch-show.el

  (notmuch-show-buttonized-link-colors):
- new defcustom, allows toggling colorization of buttonized links.

  (notmuch-show-buttonized-link-available),
  (notmuch-show-buttonized-link-available-and-unread),
  (notmuch-show-buttonized-link-missing):
- new faces for buttonized id: links.

  (notmuch-show-found-target-p):
- add optional arg SUBQUERY to allow addition filtering,
  eg. with "tag:unread".

  (notmuch-show-buttonize-links):
- tweak `Message-Id' regexp: less greedy matching.
- use different face property depending on the result of
  `notmuch-show-found-target-p', causing buttons to available,
  available-and-unread and missing messages to be displayed in
  different colors.
---

[Forgot to cc the list, apologies for the dupes.]

I've also noticed that Message-Id's from `git send-email'
don't get colorized (but do get buttonized) for some reason.
Thus, would appreciate some assistance with the regexp.


v2:

- add `notmuch-show-buttonized-link-colors': new defcustom, allows
  toggling colorization of buttonized links, to address unquestionable
  concerns re performance, voiced by David Edmondson [1].
- ... and some minor refactoring

v3:

- tweak `Message-Id' regexp: mock Message-Id's shouldn't be matched,
  as pointed out by Aaron Ecay [2].


[1] id:"cun4nvv50s6.fsf at hotblack-desiato.hh.sledj.net"
[2] id:"m2sjjfb9xx.fsf at gmail.com"


 emacs/notmuch-show.el |   47 +++
 1 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 244824a..deac9a6 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -798,6 +798,38 @@ current buffer, if possible."
 (defvar notmuch-show-buffer-name nil)
 (make-variable-buffer-local 'notmuch-show-buffer-name)

+(defcustom notmuch-show-buttonized-link-colors t
+  "Colorize buttonized links depending on their target's state.
+
+Also see `notmuch-show-buttonized-link-available',
+ `notmuch-show-buttonized-link-available-and-unread',
+ `notmuch-show-buttonized-link-missing'.
+
+Might impact performance."
+  :type 'boolean
+  :group 'notmuch-show)
+
+(defface notmuch-show-buttonized-link-available
+  '((t (:inherit goto-address-mail-face :foreground "blue")))
+  "Face used for buttonized links to messages which are present
+in the mail store."
+  :group 'notmuch-show
+  :group 'notmuch-faces)
+
+(defface notmuch-show-buttonized-link-available-and-unread
+  '((t (:inherit goto-address-mail-face :foreground "green")))
+  "Face used for buttonized links to messages which are present
+in the mail store, and are tagged `unread'."
+  :group 'notmuch-show
+  :group 'notmuch-faces)
+
+(defface notmuch-show-buttonized-link-missing
+  '((t (:inherit goto-address-mail-face :foreground "red")))
+  "Face used for buttonized links to messages which are NOT
+present in in the mail store."
+  :group 'notmuch-show
+  :group 'notmuch-faces)
+
 (defun notmuch-show-buttonize-links (start end)
   "Buttonize URLs and mail addresses between START and END.

@@ -806,7 +838,7 @@ a corresponding notmuch search."
   (goto-address-fontify-region start end)
   (save-excursion
 (goto-char start)
-(while (re-search-forward "id:\\(\"?\\)[^[:space:]\"]+\\1" end t)
+(while (re-search-forward "id:\\(\"?\\)\[^ \t\"@\]\+@[^ \t\"]\+\\1" end t)
   (let ((message-id (match-string-no-properties 0))
(string-start (match-beginning 0))
(string-end (match-end 0)))
@@ -817,7 +849,14 @@ a corresponding notmuch search."
 (notmuch-show-if-found ,message-id))
  'follow-link t
  'help-echo "Mouse-1, RET: search for this message"
- 'face goto-address-mail-face)
+ 'face (if notmuch-show-buttonized-link-colors
+   (cond
+((notmuch-show-found-target-p message-id 
"and tag:unread")
+ 
'notmuch-show-buttonized-link-available-and-unread)
+((notmuch-show-found-target-p message-id 
nil)
+ 'notmuch-show-buttonized-link-available)
+(t 'notmuch-show-buttonized-link-missing))
+ 'goto-address-mail-face))

 ;;;###autoload
 (defun notmuch-show (thread-id  parent-buffer query-context 
buffer-name crypto-switch)
@@ -910,8 +949,8 @@ thread id.  If a prefix is given, crypto processing is 
toggled."
 (notmuch-kill-this-buffer)
 (notmuch-show-worker thread-id parent-buffer query-context buffer-name 
process-crypto)))

-(defun notmuch-show-found-target-p (target)
-  (let ((args `("count" ,target)))
+(defun notmuch-show-found-target-p (target  subquery)
+  (let ((args `("count" ,target ,(or subquery ""
 (> (string-to-number
   

[PATCH v4] emacs: logically group def{custom,face}s

[Austin Clements]

Quoth Pieter Praet on Jan 18 at 11:00 am:
> On Mon, 16 Jan 2012 14:16:22 -0500, Austin Clements  
> wrote:
> > LGTM.
> > 
> > Quoth Pieter Praet on Jan 16 at 11:38 am:
> > > - Add `notmuch-send' to the `message' group, as per Austin's
> > >   recommendation [1].
> > 
> > This is actually the reverse of what I was suggesting (though is also
> > reasonable).  Since notmuch uses message-mode, I was saying that the
> > notmuch group (or the notmuch-send group) should link to the message
> > group.  That way, if you customize-group notmuch, you get all of the
> > options that affect notmuch, even those that aren't strictly notmuch
> > variables.
> 
> Sorry, failed to mention;  I tried that, but the additional
> 
>   :link '(custom-group-link :tag "Message" message)
> 
> didn't seem all that useful compared to (or combined with)
> adding `message' as parent group to `notmuch-send':
> 
>   #+begin_example
> Parent groups: Message Notmuch
> 
> /- Notmuch Send group: Sending messages from Notmuch.\
>   State: something in this group has been changed outside customize.
>   #+end_example
> 
> vs.
> 
>   #+begin_example
> Parent groups: Message Notmuch
> 
> /- Notmuch Send group: Sending messages from Notmuch.\
>   State: something in this group has been changed outside customize.
>   See also Message.
>   #+end_example
> 
> ... so I ripped it out again.  Should I add it back?

Hmm.  You're right that the :link doesn't do much.

One other possibility to consider is
  (custom-add-to-group 'notmuch-show 'message 'custom-group)
or even
  (custom-add-to-group 'notmuch 'message 'custom-group)

RFC: tag macros

[Austin Clements]

Quoth David Bremner on Jan 18 at 10:45 am:
> 
> Hi All;
> 
> Here is a very early stage proposal to provide tagging macros for
> notmuch show mode. 
> 
> The idea is that user defines a mapping from single key to a sequence of
> tagging operations.  It might be nice if there as some kind of pop-up
> menu, or at least a prompt, but I didn't do that so far.
> 
> The advantage of this rather than just writing lots of little lambdas is
> that it combines adding and deleting, and it could be done via
> customize.
> 
> As provided, the code should just paste into .emacs, and with a little
> editing into notmuch-show.el.

What about simply providing an API that takes a bunch of tag
operations and applies them to the current thread/message/region?
Maybe even the notmuch-show-add-or-del-tags that you have below
(probably spruced up a bit).  I feel like the type of people who are
likely to use tag macros would also have the know-how to add a simple
key binding of their own, assuming it *were* simple.  Such an API
would probably clean up some of the tagging code in notmuch-show, too.

[PATCH] test: always report missing prereqs, independent of `--verbose' option

[Pieter Praet]

When tests are skipped due to missing prereqs, those prereqs are only
displayed when running with the `--verbose' option.  This is essential
information when troubleshooting, so always send to stdout.

---

 test/test-lib.sh |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/test/test-lib.sh b/test/test-lib.sh
index d1fbc05..6560628 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -673,8 +673,8 @@ test_skip () {

 test_check_missing_external_prereqs_ () {
if test -n "$test_subtest_missing_external_prereqs_"; then
-   say_color skip >&3 "missing prerequisites:"
-   echo "$test_subtest_missing_external_prereqs_" >&3
+   say_color skip >&1 "missing prerequisites:"
+   echo "$test_subtest_missing_external_prereqs_" >&1
test_report_skip_ "$@"
else
false
-- 
1.7.8.1

[PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Pieter Praet]

On Wed, 18 Jan 2012 10:13:35 +, David Edmondson  wrote:
> On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet  wrote:
> > > [...] What's wrong with '(loop ... collect ...)'?
> > 
> > Nothing at all.  I was fixing my own patch [1] without resorting to
> > requiring the `cl' package at runtime :)  Would be nice if we could
> > get rid of the compile-time dependency as well, though.
> 
> Can you explain why it's necessary at runtime?

Because otherwise `remove-if-not' and `member-if-not' would
be void, as you alluded to previously [1,2].


Peace

-- 
Pieter

[1] id:"cunvcob52ku.fsf at hotblack-desiato.hh.sledj.net"
[2] id:"cun1uqz50p4.fsf at hotblack-desiato.hh.sledj.net"

[PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[David Edmondson]

On Wed, 18 Jan 2012 13:15:55 +0100, Pieter Praet  wrote:
> On Wed, 18 Jan 2012 10:13:35 +, David Edmondson  wrote:
> > On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet  
> > wrote:
> > > > [...] What's wrong with '(loop ... collect ...)'?
> > > 
> > > Nothing at all.  I was fixing my own patch [1] without resorting to
> > > requiring the `cl' package at runtime :)  Would be nice if we could
> > > get rid of the compile-time dependency as well, though.
> > 
> > Can you explain why it's necessary at runtime?
> 
> Because otherwise `remove-if-not' and `member-if-not' would
> be void, as you alluded to previously [1,2].

Ah, not macros. Sorry for being slow.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/363500eb/attachment-0001.pgp>

[PATCH v2 2/2] Add pseudo-compatibility with gmime 2.6

[Tom Prince]

On Tue, 17 Jan 2012 11:50:53 +0100, Thomas Jost  
wrote:
> This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
> crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test
> fails (signature verification with signer key unavailable) but this will be 
> hard
> to fix since the new API does not report the reason why a signature 
> verification
> fails (other than the human-readable error message).

How did you test against multiple versions? Using different machines? If
there was a way for configure (or something to pick the version, I would
setup the buildbot to test against both, so we don't regress either.

  Tom

RFC: tag macros

[Jameson Graef Rollins]

On Wed, 18 Jan 2012 15:03:52 -0400, David Bremner  wrote:
> My main motivation here is (as you can probably see from the example)
> dealing with patches, and in that setting, tagging the whole thread is
> is almost never what you want.

The example I sent was about tagging individual message, not threads.

> That aside, thread tagging is already there in search view, and I guess
> could be done by selecting the whole thread and tagging that region.

Thread tagging would be supported in show mode with the recent
notmuch-show-{add,remove}-tag-thread patches I sent:

id:"1326823531-14549-1-git-send-email-jrollins at finestructure.net"

> I haven't really looked at how to apply tags to regions in
> notmuch-show-mode. Is there code around that does that? Or more
> generally iterate over messages in a region?

I don't think the show mode tagging functions support regions at the
moment, but I think extending them to do that would be a good idea.

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/20120118/2a5fc7b2/attachment-0001.pgp>

[PATCH 2/3] test: Add `test_emacs_expect_t'.

[Tomi Ollila]

On Tue, 17 Jan 2012 15:09:22 +, David Edmondson  wrote:
> On Tue, 17 Jan 2012 18:49:36 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > > + # We cannot call 'test_emacs' in a subshell, because
> > > + # the setting of EMACS_SERVER would not persist
> > > + # throughout a sequence of tests, so we use a
> > > + # temporary file.
> > > + tmp="$TMPDIR"; if [ -z "$tmp" ]; then tmp=/tmp; fi
> > > + output="$tmp/test_emacs_output.$$"
> > > + test_emacs "$1" > "${output}"
> > > + result=$(cat "${output}")
> > > + rm -f "${output}"
> > 
> > I wonder if there is any bash trick which can help here?
> 
> I'm not aware of one, but I'm not a bash expert.

No shell trick possible there.

> 
> > Another option is to start emacs server before using test_emacs in
> > subshell.  See emacs-subject-to-filename for an example.  I think this
> > is a better option than using a temporary file.
> 
> I think that's a very poor option. Forcing knowledge the breakage into
> all of the users may make applying any future fix more difficult.

The alternative would be to replace
emacsclient --socket-name="$EMACS_SERVER" --eval "(progn $@)"

with something like:

   case $1 in --stdout-to-output)
shift
output=$(emacsclient --socket-name="$EMACS_SERVER" --eval "(progn $@)")
return
   esac
   emacsclient --socket-name="$EMACS_SERVER" --eval "(progn $@)"

Tomi

[PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Pieter Praet]

On Mon, 16 Jan 2012 23:10:27 +0200, Jani Nikula  wrote:
> On Mon, 16 Jan 2012 17:46:55 +0100, Pieter Praet  wrote:
> > Make `notmuch-cycle-notmuch-buffers' more Lispy and merge into `notmuch',
> > eliminating the need to hog yet another keybind.
> 
> What does "merge" mean here? [...]

"One function ought to be enough for anybody." ? :) [1]


> [...] Will it still be possible for me to hit one
> key to unconditionally get to notmuch-hello, and another to cycle
> through the buffers? I wouldn't want to lose that ability.
> 

Sure, but then your new key should be bound to `notmuch' instead
of `notmuch-cycle-notmuch-buffers', and the key originally bound
to `notmuch' should be remapped to `notmuch-hello'.


> > ---
> >  emacs/notmuch.el |   40 ++--
> >  1 files changed, 14 insertions(+), 26 deletions(-)
> > 
> > diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> > index ef4dcc7..539b3a0 100644
> > --- a/emacs/notmuch.el
> > +++ b/emacs/notmuch.el
> > @@ -1067,7 +1067,20 @@ current search results AND that are tagged with the 
> > given tag."
> >  (defun notmuch ()
> >"Run notmuch and display saved searches, known tags, etc."
> >(interactive)
> > -  (notmuch-hello))
> > +  (let* ((old-buffer (current-buffer))
> > +(interesting-buffers
> > + (delq nil (mapcar (lambda (b)
> > + (if (notmuch-interesting-buffer b) b))
> > +   (buffer-list
> > +(next-buffer (first
> > + (delq nil (mapcar (lambda (b)
> > + (unless (eq old-buffer b) b))
> > +   interesting-buffers)
> > +(if next-buffer
> > +   (progn
> > + (switch-to-buffer next-buffer)
> > + (bury-buffer old-buffer))
> > +  (notmuch-hello
> 
> notmuch-cycle-notmuch-buffers pretty much explains in the name what it
> does, but additionally it has documentation, and explanatory
> comments. Please don't drop those.
> 

Agreed.


Less intrusive patch available [2].


> BR,
> Jani
> 
> 
> 
> >  
> >  (defun notmuch-interesting-buffer (b)
> >"Is the current buffer of interest to a notmuch user?"
> > @@ -1078,31 +1091,6 @@ current search results AND that are tagged with the 
> > given tag."
> >message-mode
> >  
> >  ;;;###autoload
> > -(defun notmuch-cycle-notmuch-buffers ()
> > -  "Cycle through any existing notmuch buffers (search, show or hello).
> > -
> > -If the current buffer is the only notmuch buffer, bury it. If no
> > -notmuch buffers exist, run `notmuch'."
> > -  (interactive)
> > -
> > -  (let (start first)
> > -;; If the current buffer is a notmuch buffer, remember it and then
> > -;; bury it.
> > -(when (notmuch-interesting-buffer (current-buffer))
> > -  (setq start (current-buffer))
> > -  (bury-buffer))
> > -
> > -;; Find the first notmuch buffer.
> > -(setq first (loop for buffer in (buffer-list)
> > -if (notmuch-interesting-buffer buffer)
> > -return buffer))
> > -
> > -(if first
> > -   ;; If the first one we found is any other than the starting
> > -   ;; buffer, switch to it.
> > -   (unless (eq first start)
> > - (switch-to-buffer first))
> > -  (notmuch
> >  
> >  (setq mail-user-agent 'notmuch-user-agent)
> >  
> > -- 
> > 1.7.8.1
> > 
> > ___
> > notmuch mailing list
> > notmuch at notmuchmail.org
> > http://notmuchmail.org/mailman/listinfo/notmuch


Peace

-- 
Pieter

[1] http://www.computerworld.com/s/article/9101699
[2] id:"1326881084-25432-1-git-send-email-pieter at praet.org"

[RFC] [PATCH v3] emacs: rewrite `notmuch-cycle-notmuch-buffers'

[Pieter Praet]

Get rid of the compile-time `cl' requirement for this particular function.

---
 emacs/notmuch.el |   40 ++--
 1 files changed, 22 insertions(+), 18 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index ef4dcc7..2426c0a 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -1084,24 +1084,28 @@ current search results AND that are tagged with the 
given tag."
 If the current buffer is the only notmuch buffer, bury it. If no
 notmuch buffers exist, run `notmuch'."
   (interactive)
-
-  (let (start first)
-;; If the current buffer is a notmuch buffer, remember it and then
-;; bury it.
-(when (notmuch-interesting-buffer (current-buffer))
-  (setq start (current-buffer))
-  (bury-buffer))
-
-;; Find the first notmuch buffer.
-(setq first (loop for buffer in (buffer-list)
-if (notmuch-interesting-buffer buffer)
-return buffer))
-
-(if first
-   ;; If the first one we found is any other than the starting
-   ;; buffer, switch to it.
-   (unless (eq first start)
- (switch-to-buffer first))
+  (let* ((old-buffer (current-buffer))
+(next-buffer (first
+ ;; Find interesting buffers:
+ ;; Loop over all existing buffers and return those that
+ ;; satisfy the predicate (`notmuch-interesting-buffer' and
+ ;; not `eq' to current buffer) integrally;  All others are
+ ;; replaced with `nil'.  Then strip out all `nil's using
+ ;; `delq'.  Basically a re-implementation of `cl' package's
+ ;; `delete-if-not'.
+ (delq nil
+  (mapcar (lambda (b)
+(and (notmuch-interesting-buffer b)
+ (not (eq old-buffer b))
+ b))
+  (buffer-list))
+
+;; If there's a next buffer, switch to it and bury the
+;; original current buffer.  Otherwise run `notmuch-hello'.
+(if next-buffer
+   (progn
+ (switch-to-buffer next-buffer)
+ (bury-buffer old-buffer))
   (notmuch

 (setq mail-user-agent 'notmuch-user-agent)
-- 
1.7.8.1

[PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Pieter Praet]

On Mon, 16 Jan 2012 17:03:44 +, David Edmondson  wrote:
> On Mon, 16 Jan 2012 17:46:55 +0100, Pieter Praet  wrote:
> > Make `notmuch-cycle-notmuch-buffers' more Lispy and merge into `notmuch',
> > eliminating the need to hog yet another keybind.
> ...
> > diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> > index ef4dcc7..539b3a0 100644
> > --- a/emacs/notmuch.el
> > +++ b/emacs/notmuch.el
> > @@ -1067,7 +1067,20 @@ current search results AND that are tagged with the 
> > given tag."
> >  (defun notmuch ()
> >"Run notmuch and display saved searches, known tags, etc."
> >(interactive)
> > -  (notmuch-hello))
> > +  (let* ((old-buffer (current-buffer))
> > +(interesting-buffers
> > + (delq nil (mapcar (lambda (b)
> > + (if (notmuch-interesting-buffer b) b))
> > +   (buffer-list
> > +(next-buffer (first
> > + (delq nil (mapcar (lambda (b)
> > + (unless (eq old-buffer b) b))
> > +   interesting-buffers)
> 
> This feels _less_ lispy. [...]

True.  I simply re-implemented `delete-if-not' in order to
prevent having to require the `cl' package at runtime.
(why on Earth isn't there an equivalent function in plain Elisp ?!?)

  $ sed -e "s/C\?Lisp\(y\|'ier\)/Elispy/" $COMMIT_MSG


> [...] Any occurrences of '(delq nil ...)' strike me
> as odd. [...]

How so?  Lacking a flexible way to conditionally remove elements from a
list (that doesn't require the `cl' package in some way or another),
a combination of `mapcar' and `delq' seemed like the easiest approach.

(AFAIK;  Please correct me if (when) I'm wrong!)


> [...] What's wrong with '(loop ... collect ...)'?
> 

Nothing at all.  I was fixing my own patch [1] without resorting to
requiring the `cl' package at runtime :)  Would be nice if we could
get rid of the compile-time dependency as well, though.

Fresh patch to that effect follows.

Feel free to disregard it, just bikesheddin'...


> > +(if next-buffer
> > +   (progn
> > + (switch-to-buffer next-buffer)
> > + (bury-buffer old-buffer))
> > +  (notmuch-hello
> 
> Integrating with `notmuch' is fine with me.


Peace

-- 
Pieter

[1] id:"1326710551-23122-1-git-send-email-pieter at praet.org"

[PATCH v4] emacs: logically group def{custom,face}s

[Pieter Praet]

On Mon, 16 Jan 2012 14:16:22 -0500, Austin Clements  wrote:
> LGTM.
> 
> Quoth Pieter Praet on Jan 16 at 11:38 am:
> > - Add `notmuch-send' to the `message' group, as per Austin's
> >   recommendation [1].
> 
> This is actually the reverse of what I was suggesting (though is also
> reasonable).  Since notmuch uses message-mode, I was saying that the
> notmuch group (or the notmuch-send group) should link to the message
> group.  That way, if you customize-group notmuch, you get all of the
> options that affect notmuch, even those that aren't strictly notmuch
> variables.

Sorry, failed to mention;  I tried that, but the additional

  :link '(custom-group-link :tag "Message" message)

didn't seem all that useful compared to (or combined with)
adding `message' as parent group to `notmuch-send':

  #+begin_example
Parent groups: Message Notmuch

/- Notmuch Send group: Sending messages from Notmuch.\
  State: something in this group has been changed outside customize.
  #+end_example

vs.

  #+begin_example
Parent groups: Message Notmuch

/- Notmuch Send group: Sending messages from Notmuch.\
  State: something in this group has been changed outside customize.
  See also Message.
  #+end_example

... so I ripped it out again.  Should I add it back?


Peace

-- 
Pieter

[PATCH 4/6] emacs: add option to notmuch-show-next-open-message to pop out to parent buffer if at end

[Jameson Graef Rollins]

On Wed, 18 Jan 2012 08:56:26 +, David Edmondson  wrote:
> I'm used to the cursor going to the bottom of the thread to let me know
> that I reached the end, then I hit 'space' and move on to the next
> thread. Will that behaviour be retained with this patch? (Well,
> including your other patch which seemed to set `pop-at-end'.)

This doesn't change the default behavior of the 'n' key, if that's what
you're asking, so the behavior you're describing should work the same.

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/20120118/ed24d005/attachment.pgp>

[PATCH v2 3/3] search: Support automatic tag exclusions

[Jameson Graef Rollins]

On Wed, 18 Jan 2012 09:52:52 +, David Edmondson  wrote:
> I agree that as long as no keys are pre-bound it will make little
> difference. That just transfers the discussion to the thread about
> adding the bindings, which seems silly.

I think that's ok.  The tag exclusion is in, which is great.  The
next question, of whether we should setup excludes by default, is
intimately related to whether or not we support key bindings to add
those tags.  So I think it's fine to transfer the rest of this
discussion to that thread.

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/20120118/fa579212/attachment.pgp>

RFC: tag macros

[Jameson Graef Rollins]

On Wed, 18 Jan 2012 10:45:06 -0400, David Bremner  wrote:
> The advantage of this rather than just writing lots of little lambdas is
> that it combines adding and deleting, and it could be done via
> customize.

Is all of this really easier than just adding the following to your
.emacs?:

(define-key notmuch-search-mode-map "o"
  (lambda ()
(interactive)
(notmuch-show-add-tag "notmuch::patch")
(notmuch-show-add-tag "notmuch::obsolete")
(notmuch-show-remove-tag "notmuch::needs-review")))

That seems really simple to me, and doesn't require us to support a
bunch of code to do complicated customization stuff.

Rather than have protracted conversations about key bindings or continue
to make more complicated configuration setups, I would like to push the
idea that we support a bunch of nice simple functions to do common,
useful operations (like tagging and navigation), and let users build
macros as they see fit.  I think this is a lot more flexible, and takes
a lot of the maintenance burden off of us.

I've been wanting to put together a wiki page that lists all the useful
functions and has examples of how to put them together into useful
functions.

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/20120118/4b3fae89/attachment-0001.pgp>

[PATCH v3] Make buttons for attachments allow viewing as well as saving

[Mark Walters]

> > +(defun notmuch-show-view-part (message-id nth  filename 
> > content-type )
> > +  (notmuch-with-temp-part-buffer message-id nth
> > +;; set mm-inlined-types to nil to force an external viewer
> > +(let ((handle (mm-make-handle (current-buffer) (list content-type)))
> > + (mm-inlined-types nil))
> > +  ;; We override mm-save-part as notmuch-show-save-part is better
> > +  ;; since it offers the filename
> > +  (flet ((mm-save-part ( args) (ignore)))
> > +   (or (mm-display-part handle)
> > +   (notmuch-show-save-part message-id nth filename 
> > content-type))
> > 
> > Is that a reasonable solution? 
> 
> It's *probably* safe to depend on the result of mm-display-part, but
> you can avoid the question altogether by simply calling
> notmuch-show-save-part from your flet mm-save-part.  E.g.,
> 
> (flet ((mm-save-part ( args) (notmuch-show-save-part 
>message-id nth filename content-type)))
>   (mm-display-part handle))

Unfortunately that does not work since mm-display-part has a local
variable "filename".  I could copy the variables to some notmuch
prefixed variables but maybe there is some obvious "quoting" to avoid
the problem? (I can't easily check now as the gnu site is closed for the
day.)

Best wishes

Mark

RFC: tag macros

[David Bremner]

Hi All;

Here is a very early stage proposal to provide tagging macros for
notmuch show mode. 

The idea is that user defines a mapping from single key to a sequence of
tagging operations.  It might be nice if there as some kind of pop-up
menu, or at least a prompt, but I didn't do that so far.

The advantage of this rather than just writing lots of little lambdas is
that it combines adding and deleting, and it could be done via
customize.

As provided, the code should just paste into .emacs, and with a little
editing into notmuch-show.el.

%  cut here 

(eval-after-load 'notmuch-show
  '(define-key notmuch-show-mode-map "t" 'notmuch-show-apply-tag-macro))

(setq notmuch-show-tag-macro-alist
  (list '("p" "+notmuch::patch" "+notmuch::needs-review")
'("r" "+notmuch::review")
'("o" "+notmuch::patch" "+notmuch::obsolete" "-notmuch::needs-review")
'("m" "+notmuch::patch" "+notmuch::moreinfo" "-notmuch::needs-review")))

(defun notmuch-show-apply-tag-macro (key)
  (interactive "k")
  (let ((macro (assoc key notmuch-show-tag-macro-alist)))
(apply 'notmuch-show-add-or-del-tags (cdr macro

(defun notmuch-show-add-or-del-tags ( add-or-dels)
  "Add or delete tags to/from the current message."
  (let* ((current-tags (notmuch-show-get-tags))
 (new-tags (notmuch-show-add-or-del-tags-worker current-tags 
add-or-dels)))
(unless (equal current-tags new-tags)
  (apply 'notmuch-tag (notmuch-show-get-message-id) add-or-dels)
  (notmuch-show-set-tags new-tags


(defun notmuch-show-add-or-del-tags-worker (current-tags add-or-dels)
  "Remove any tags in `add-or-del' prefixed with `-' from `current-tags', add 
any prefixed with `+'
and return the result."
  (let (adds deletes)
(mapc (lambda (tag-str)
(if (string-match "^\\([+\-]\\)\\(.*\\)" tag-str)
(let ((op (match-string 1 tag-str))
  (tag (match-string 2 tag-str)))
  (if (equal op "+")
  (setq adds (cons tag adds))
(setq deletes (cons tag deletes
  (error "%s: does not start with + or -" tag-str)))
  add-or-dels)
(notmuch-show-del-tags-worker 
 (notmuch-show-add-tags-worker current-tags adds)
 deletes)))

[PATCH v2 2/2] Add pseudo-compatibility with gmime 2.6

[Tomi Ollila]

On Tue, 17 Jan 2012 17:25:46 -0500, Austin Clements  wrote:
> Quoth Thomas Jost on Jan 17 at 11:50 am:
> >  
> > +#ifdef GMIME_26
> > +/* sig_list may be created in both above cases, so we need to
> > + * cleanly handle it here. */
> > +if (node->sig_list) {
> > +   GMimeSignatureList **proxy =
> > +   talloc (node, GMimeSignatureList *);
> 
> This doesn't need to be split into two lines.
> 
> > +   *proxy = node->sig_list;
> > +   talloc_set_destructor (proxy, _signature_list_free);
> > +}
> > +#else
> >  if (node->verify_attempted && !node->sig_validity)
> > fprintf (stderr, "Failed to verify signed part: %s\n",
> >  (err ? err->message : "no error explanation given"));
> > +#endif
> 
> I'd rather see the above as a separate #ifdef GMIME_26 and #ifndef
> GMIME_26, since they aren't logical alternates of each other.

That reminds me that it should then be like GMIME_ATLEAST_26, so
that this might be useful when GMIME > 2.6 is available...

Tomi

[PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[David Edmondson]

On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet  wrote:
> > [...] What's wrong with '(loop ... collect ...)'?
> 
> Nothing at all.  I was fixing my own patch [1] without resorting to
> requiring the `cl' package at runtime :)  Would be nice if we could
> get rid of the compile-time dependency as well, though.

Can you explain why it's necessary at runtime?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/42844b12/attachment.pgp>

[PATCH v2 3/3] search: Support automatic tag exclusions

[David Edmondson]

On Wed, 18 Jan 2012 00:52:09 -0800, Jameson Graef Rollins  wrote:
> On Wed, 18 Jan 2012 08:38:23 +, David Edmondson  wrote:
> > Something must create the initial configuration file if none exists. I'd
> > be okay with that code adding 'deleted' and 'spam' to the excluded list.
> >
> > This would mean that an existing user would see no change without taking
> > some action (adding the tags to the configuration file) and a new user
> > would see the new behaviour (automatic exclusion).
> 
> What you describe is indeed how it currently works.  For new users or
> old users who rerun setup, the config file will automatically include
> the exclusions.  Otherwise, users will see no change.

Good, thanks.

> > I'm not completely sure that automatically adding the exclusion of the
> > specified tags via the configuration file for new users is a great
> > idea. It seems as though it will lead to confusion for someone at some
> > point.
> 
> Without any keys pre-bound to add "deleted" or "spam" tags, it probably
> won't make much difference for new users.  And as long as it's
> documented, users will be warned of the behavior.  Reading the config
> file would also make it clear how the variable changes behavior.

I agree that as long as no keys are pre-bound it will make little
difference. That just transfers the discussion to the thread about
adding the bindings, which seems silly.

Anyway, I'm not too worried - I just won't answer any of the questions
about it on the list :-)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/18e07720/attachment.pgp>

[PATCH v2 4/5] emacs: Use the new JSON reply format.

[Adam Wolfe Gordon]

Using the new JSON reply format allows emacs to quote HTML
parts nicely by using mm-display-part to turn them into displayable
text, then quoting them. This is very useful for users who
regularly receive HTML-only email.

The behavior for messages that contain plain text parts should be
unchanged.
---
 emacs/notmuch-lib.el |8 
 emacs/notmuch-mua.el |   95 +-
 2 files changed, 71 insertions(+), 32 deletions(-)

diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index 0f856bf..c5c6f91 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -21,6 +21,8 @@

 ;; This is an part of an emacs-based interface to the notmuch mail system.

+(eval-when-compile (require 'cl))
+
 (defvar notmuch-command "notmuch"
   "Command to run the notmuch binary.")

@@ -127,6 +129,12 @@ the user hasn't set this variable with the old or new 
value."
   (list 'when (< emacs-major-version 23)
form))

+(defun notmuch-parts-filter-by-type (parts type)
+  "Return a list of message parts with the given type"
+  (loop for part across parts
+   if (string= (cdr (assq 'content-type part)) type)
+   collect (cdr (assq 'content part
+
 ;; Compatibility functions for versions of emacs before emacs 23.
 ;;
 ;; Both functions here were copied from emacs 23 with the following copyright:
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index d8ab822..b5c5493 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -19,6 +19,7 @@
 ;;
 ;; Authors: David Edmondson 

+(require 'json)
 (require 'message)

 (require 'notmuch-lib)
@@ -71,49 +72,79 @@ list."
(push header message-hidden-headers)))
notmuch-mua-hidden-headers))

+(defun notmuch-mua-insert-part-quoted (part)
+  (let ((start (point))
+   limit)
+(insert part)
+(setq limit (point-marker))
+(goto-char start)
+(while (re-search-forward "\\(^\\)[^$]" (marker-position limit) 0)
+  (replace-match "> " nil nil nil 1))
+(set-buffer-modified-p nil)))
+
+(defun notmuch-mua-parse-html-part (part)
+  (with-temp-buffer
+(insert part)
+(let ((handle (mm-make-handle (current-buffer) (list "text/html")))
+ (end-of-orig (point-max)))
+  (mm-display-part handle)
+  (delete-region (point-min) end-of-orig)
+  (fill-region (point-min) (point-max))
+  (buffer-substring (point-min) (point-max)
+
 (defun notmuch-mua-reply (query-string  sender reply-all)
-  (let (headers
-   body
-   (args '("reply")))
+  (let ((args '("reply" "--format=json"))
+   reply
+   body)
 (if notmuch-show-process-crypto
(setq args (append args '("--decrypt"
 (if reply-all
(setq args (append args '("--reply-to=all")))
   (setq args (append args '("--reply-to=sender"
 (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
-;; line and then the body.
+;; Get the reply object as JSON, and parse it into an elisp object.
 (with-temp-buffer
   (apply 'call-process (append (list notmuch-command nil (list t t) nil) 
args))
   (goto-char (point-min))
-  (if (re-search-forward "^$" nil t)
- (save-excursion
-   (save-restriction
- (narrow-to-region (point-min) (point))
- (goto-char (point-min))
- (setq headers (mail-header-extract)
-  (forward-line 1)
-  (setq body (buffer-substring (point) (point-max
-;; If sender is non-nil, set the From: header to its value.
-(when sender
-  (mail-header-set 'from sender headers))
-(let
-   ;; Overlay the composition window on that being used to read
-   ;; the original message.
-   ((same-window-regexps '("\\*mail .*")))
-  (notmuch-mua-mail (mail-header 'to headers)
-   (mail-header 'subject headers)
-   (message-headers-to-generate headers t '(to subject
-;; insert the message body - but put it in front of the signature
-;; if one is present
-(goto-char (point-max))
-(if (re-search-backward message-signature-separator nil t)
+  (setq reply (aref (json-read) 0)))
+
+;; Start with the prelude, based on the headers of the original message.
+(let* ((original (cdr (assq 'original reply)))
+  (headers (cdr (assq 'headers (assq 'reply reply
+  (original-headers (cdr (assq 'headers original)))
+  (body-parts (cdr (assq 'body original)))
+  (plain-parts (notmuch-parts-filter-by-type body-parts "text/plain"))
+  (html-parts (notmuch-parts-filter-by-type body-parts "text/html")))
+
+  ;; If sender is non-nil, set the From: header to its value.
+  (when sender
+   (mail-header-set 'from sender headers))
+  (let
+ ;; Overlay the composition window on that being used to read
+ ;; the original 

[PATCH v2 4/5] emacs: Use the new JSON reply format.

[Adam Wolfe Gordon]

On Tue, Jan 17, 2012 at 23:54, David Edmondson  wrote:
> On Tue, 17 Jan 2012 15:53:37 -0700, Adam Wolfe Gordon  
> wrote:
>> +(defun notmuch-parts-filter-by-type (parts type)
>> + ?"Return a list of message parts with the given type"
>> + ?(let (result)
>> + ? ?(dolist (part (append parts nil) result)
>> + ? ? ?(if (string= (cdr (assq 'content-type part)) type)
>> + ? ? ? (setq result (append result (list (cdr (assq 'content part)))
>> + ? ?result))
>
> I still think that `loop' is easier to read :-) But no objection to this
> code.

I couldn't find the loop construct initially, but after the discussion
of common lisp on IRC yesterday I found the cl package and figured out
how your example worked.  With loop and collect figured out, it is
easier to read.

>> +(defun notmuch-mua-insert-part-quoted (part)
>> + ?(let ((start (point))
>> + ? ? limit)
>> + ? ?(insert part)
>> + ? ?(setq limit (point))
>> + ? ?(goto-char start)
>> + ? ?(while (re-search-forward "\\(^\\)[^$]" limit 0)
>> + ? ? ?(replace-match "> " nil nil nil 1)
>> + ? ? ?;; We have added two characters to the quotable region
>> + ? ? ?(setq limit (+ limit 2)))
>> + ? ?(set-buffer-modified-p nil)))
>
> You could use a marker for the limit, as it would then move along
> automagically (sorry for not noticing this last time).

Aha!  Another trick I didn't know about.

New patch forthcoming.

ANNOUNCE: nottoomuch-addresses.sh 2.0

[Tomi Ollila]

nottoomuch-addresses.sh -- email address substring matcher
-- completion helper version 2.0 is available.

Note to 1.92 prerelease tester(s): ignore regexp "indicator"
has changed from ^re:... to ^/.../[i]. This allows this 'i'
flag and trailing whitespace in re.

Changes:
   * Added regexp-based ignores using /regexp/[i] syntax in ignore file.
   * Addresses 'cache' now contains all addresses and filreted (by ignore)
 are now in separate file. This way changes in ignore filters can be
 propagated to active address list.
   * Encoded address content is now recursively decoded.

Header version was changed but this version supports "importing"
data from older versions. In case you had ignore filters defined
(or recursively encoded mailbox/comment names) it is recommended
to rebuils address cache with

/path/to/nottoomuch-addresses.sh --update --rebuild

Location: http://www.iki.fi/too/nottoomuch/nottoomuch-addresses.sh

Sha1sum (not md5sum): 343833fce0a30ddae859eff4a31d6153fa9c81f9

Web page: http://www.iki.fi/too/nottoomuch/nottoomuch-addresses/

Enjoy!
Tomi

[PATCH 4/6] emacs: add option to notmuch-show-next-open-message to pop out to parent buffer if at end

[David Edmondson]

On Wed, 18 Jan 2012 00:47:11 -0800, Jameson Graef Rollins  wrote:
> > >  (while (and (setq r (notmuch-show-goto-message-next))
> > >   (not (notmuch-show-message-visible-p
> > >  (if r
> > >   (progn
> > > (notmuch-show-mark-read)
> > > (notmuch-show-message-adjust))
> > > -  (goto-char (point-max)
> > > +  (if (and parent-buffer pop-at-end)
> > > +   (progn
> > > + (kill-this-buffer)
> > > + (switch-to-buffer parent-buffer)
> > > + (forward-line 1))
> > > + (goto-char (point-max))
> > 
> > Can you explain in words how this is expected to behave please?
> 
> Do you see a problem?

Not a problem, just trying to understand the behaviour (I have to revive
my advance/rewind patches at some point).

> If there is not another message, but there is a parent buffer and the
> pop-at-end variable is set, kill this buffer, go the parent, and move to
> the next thread.  Otherwise, go to the max point in the buffer.

I'm used to the cursor going to the bottom of the thread to let me know
that I reached the end, then I hit 'space' and move on to the next
thread. Will that behaviour be retained with this patch? (Well,
including your other patch which seemed to set `pop-at-end'.)

It's one of those things that I have to try out to understand properly I
expect.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/59a2b240/attachment.pgp>

[PATCH v2 3/3] search: Support automatic tag exclusions

[David Edmondson]

On Tue, 17 Jan 2012 15:32:11 -0500, Austin Clements  wrote:
> Quoth David Edmondson on Jan 17 at  9:08 am:
> > On Mon, 16 Jan 2012 15:16:24 -0700, Jeremy Nickurak  
> > wrote:
> > > On Mon, Jan 16, 2012 at 12:28, Austin Clements  
> > > wrote:
> > > >> Having "deleted" and "spam" as default settings in the configuration
> > > >> file might be more reasonable.
> > > 
> > > If I read correctly:
> > > 
> > > 1) If no exclude options are in the config file, none should be used.
> > 
> > Yes.
> > 
> > > 2) On notmuch setup, "deleted" and "spam" should be added to 
> > > .notmuch-config
> > 
> > I might argue between 'should' and 'could', but the sense is correct.
> 
> Oh, I think I see.  I don't know if I can do precisely that, since the
> config code doesn't know if it's being called from setup, but is
> something like this essentially what you're suggesting?
> 
> if (notmuch_config_get_auto_exclude_tags (config, ) == NULL) {
> if (is_new) {
> const char *tags[] = { "deleted", "spam" };
> notmuch_config_set_auto_exclude_tags (config, tags, 2);
> } else {
> notmuch_config_set_auto_exclude_tags (config, NULL, 0);
> }
> }
> 
> (where is_new is TRUE if this is a brand-new config file)

I'm not sure, as I haven't looked at the configuration code at
all, sorry.

Something must create the initial configuration file if none exists. I'd
be okay with that code adding 'deleted' and 'spam' to the excluded list.

This would mean that an existing user would see no change without taking
some action (adding the tags to the configuration file) and a new user
would see the new behaviour (automatic exclusion).

I'm not completely sure that automatically adding the exclusion of the
specified tags via the configuration file for new users is a great
idea. It seems as though it will lead to confusion for someone at some
point.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/c35a4c1c/attachment.pgp>

[PATCH 3/3] emacs: bind "s" to `notmuch-hello-search' in notmuch-hello buffer

[David Edmondson]

+1.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/7d227ee8/attachment.pgp>

[PATCH 2/3] emacs: use a single history for all searches

[David Edmondson]

On Tue, 17 Jan 2012 23:34:09 +0400, Dmitry Kurochkin  wrote:
> There are two ways to do search in Emacs UI: search widget in
> notmuch-hello buffer and `notmuch-search' function bound to "s".
> Before the change, these search mechanisms used different history
> lists.  The patch makes notmuch-hello search use the same history list
> as `notmuch-search' function.

The test output updates included here should be with the previous patch,
shouldn't they?

> -(defun notmuch-search (query  oldest-first target-thread 
> target-line continuation)
> -  "Run \"notmuch search\" with the given query string and display results.
> +(defun notmuch-search ( query oldest-first target-thread 
> target-line continuation)
> +  "Run \"notmuch search\" with the given `query' and display results.
>  
> -The optional parameters are used as follows:
> +If `query' is nil, it is read interactively from the minibuffer.
> +Other optional parameters are used as follows:
>  
>oldest-first: A Boolean controlling the sort order of returned threads
>target-thread: A thread ID (with the thread: prefix) that will be made
>   current if it appears in the search results.
>target-line: The line number to move to if the target thread does not
> appear in the search results."
> -  (interactive (list (notmuch-read-query "Notmuch search: ")))
> +  (interactive)
> +  (if (null query)
> +  (setq query (notmuch-read-query "Notmuch search: "))
> +(setq query (notmuch-trim query))
> +(let ((history-delete-duplicates t))
> +  (add-to-history 'notmuch-search-history query)))

Should user-typed queries be trimmed?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/d8d52410/attachment.pgp>

[PATCH 1/3] emacs: bind "s" to `notmuch-search' in notmuch-hello buffer

[David Edmondson]

Looks fine.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/09e6f4e2/attachment.pgp>

on deleting messages

[David Edmondson]

Add the bindings. Provide documentation that makes it clear that they
just add tags and never delete anything.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/ae996d3b/attachment-0001.pgp>

[PATCH 1/6] emacs: break up notmuch-show-archive-thread-internal into two generally useful functions

[David Edmondson]

On Tue, 17 Jan 2012 12:17:54 -0800, Jameson Graef Rollins  wrote:
> On Tue, 17 Jan 2012 15:10:40 -0500, Aaron Ecay  wrote:
> > This should be a docstring instead of a comment.  (This applies equally
> > to the old version)
> 
> We're not currently in the habit of adding doc strings for
> non-interactive programs.  Do we need to go down that route?

They are nice to have, especially if we already have the comment.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/135308bc/attachment.pgp>

[PATCH 6/6] emacs: modify the default show-mode key bindings for archiving

[David Edmondson]

+1.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/3f8b5131/attachment.pgp>

[PATCH 4/6] emacs: add option to notmuch-show-next-open-message to pop out to parent buffer if at end

[David Edmondson]

On Tue, 17 Jan 2012 10:05:29 -0800, Jameson Graef Rollins  wrote:
> -(defun notmuch-show-next-open-message ()
> +(defun notmuch-show-next-open-message ( pop-at-end)
>"Show the next message."
>(interactive)
> -  (let (r)
> +  (let ((r)
> + (parent-buffer notmuch-show-parent-buffer))

No need for brackets around `r'. Please put initialised local variables
before uninitialised.

>  (while (and (setq r (notmuch-show-goto-message-next))
>   (not (notmuch-show-message-visible-p
>  (if r
>   (progn
> (notmuch-show-mark-read)
> (notmuch-show-message-adjust))
> -  (goto-char (point-max)
> +  (if (and parent-buffer pop-at-end)
> +   (progn
> + (kill-this-buffer)
> + (switch-to-buffer parent-buffer)
> + (forward-line 1))
> + (goto-char (point-max))

Can you explain in words how this is expected to behave please?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/3adc8311/attachment.pgp>

[PATCH 3/6] emacs: add message archiving functions

[David Edmondson]

+1.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/b469d8f1/attachment.pgp>

[PATCH 2/6] emacs: break out thread navigation from notmuch-show-archive-thread

[David Edmondson]

+1.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/0eb2956e/attachment.pgp>

[PATCH 1/6] emacs: break up notmuch-show-archive-thread-internal into two generally useful functions

[David Edmondson]

Very happy with the overall ideas.

On Tue, 17 Jan 2012 10:05:26 -0800, Jameson Graef Rollins  wrote:
> -(defun notmuch-show-archive-thread-internal (show-next)
> -  ;; Remove the tag from the current set of messages.
> +(defun notmuch-show-tag-thread-internal (tag  remove)
> +  ;; Add tag to the current set of messages.  If the remove switch is
> +  ;; given, tags will be removed instead of added.
>(goto-char (point-min))
> -  (loop do (notmuch-show-remove-tag "inbox")
> - until (not (notmuch-show-goto-message-next)))
> -  ;; Move to the next item in the search results, if any.
> +  (let ((tag-function 'notmuch-show-add-tag))
> +(if remove
> + (setq tag-function 'notmuch-show-remove-tag))

This seems odd. How about:

 (let ((tag-function (if remove 'notmuch-show-remove-tag 
'notmuch-show-add-tag)))
  ...

> +(loop do (funcall tag-function tag)
> +   until (not (notmuch-show-goto-message-next)

Otherwise good.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/3b9a1657/attachment.pgp>

[PATCH] emacs: Improved printing support.

[David Edmondson]

Add various functions to print notmuch messages and tie them together
with a simple frontend.

Add a binding ('#') in `notmuch-show-mode' to print the current
message.
---

Updates based on Aaron's review - the comments were very useful in
improving things - thanks!

Add a keybinding to `notmuch-show-mode'.

 emacs/Makefile.local   |3 +-
 emacs/notmuch-print.el |   85 
 emacs/notmuch-show.el  |   53 ++
 3 files changed, 140 insertions(+), 1 deletions(-)
 create mode 100644 emacs/notmuch-print.el

diff --git a/emacs/Makefile.local b/emacs/Makefile.local
index 0c58b82..4fee0e8 100644
--- a/emacs/Makefile.local
+++ b/emacs/Makefile.local
@@ -13,7 +13,8 @@ emacs_sources := \
$(dir)/notmuch-maildir-fcc.el \
$(dir)/notmuch-message.el \
$(dir)/notmuch-crypto.el \
-   $(dir)/coolj.el
+   $(dir)/coolj.el \
+   $(dir)/notmuch-print.el

 emacs_images := \
$(srcdir)/$(dir)/notmuch-logo.png
diff --git a/emacs/notmuch-print.el b/emacs/notmuch-print.el
new file mode 100644
index 000..77f10bb
--- /dev/null
+++ b/emacs/notmuch-print.el
@@ -0,0 +1,85 @@
+;; notmuch-print.el --- printing messages from notmuch.
+;;
+;; Copyright ? David Edmondson
+;;
+;; This file is part of Notmuch.
+;;
+;; Notmuch is free software: you can redistribute it and/or modify it
+;; under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+;;
+;; Notmuch is distributed in the hope that it will be useful, but
+;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+;; General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with Notmuch.  If not, see .
+;;
+;; Authors: David Edmondson 
+
+(defcustom notmuch-print-mechanism 'notmuch-print-lpr
+  "How should printing be done?"
+  :group 'notmuch
+  :type '(choice
+ (function :tag "Use lpr" notmuch-print-lpr)
+ (function :tag "Use ps-print" notmuch-print-ps-print)
+ (function :tag "Use ps-print then evince" 
notmuch-print-ps-print/evince)
+ (function :tag "Use muttprint" notmuch-print-muttprint)
+ (function :tag "Use muttprint then evince" 
notmuch-print-muttprint/evince)
+ (function :tag "Using a custom function")))
+
+;; Utility functions:
+
+(defun notmuch-print-run-evince (file)
+  "View FILE using 'evince'."
+  (start-process "evince" nil "evince" file))
+
+(defun notmuch-print-run-muttprint ( output)
+  "Pass the contents of the current buffer to 'muttprint'.
+
+Optional OUTPUT allows passing a list of flags to muttprint."
+  (apply #'call-process-region (point-min) (point-max)
+;; Reads from stdin.
+"muttprint"
+nil nil nil
+;; Show the tags.
+"--printed-headers" "Date_To_From_CC_Newsgroups_*Subject*_/Tags/"
+output))
+
+;; User-visible functions:
+
+(defun notmuch-print-lpr (msg)
+  "Print a message buffer using lpr."
+  (lpr-buffer))
+
+(defun notmuch-print-ps-print (msg)
+  "Print a message buffer using the ps-print package."
+  (let ((subject (plist-get (notmuch-show-get-prop :headers msg) :Subject)))
+(rename-buffer subject t)
+(ps-print-buffer)))
+
+(defun notmuch-print-ps-print/evince (msg)
+  "Preview a message buffer using ps-print and evince."
+  (let ((ps-file (make-temp-file "notmuch"))
+   (subject (plist-get (notmuch-show-get-prop :headers msg) :Subject)))
+(rename-buffer subject t)
+(ps-print-buffer ps-file)
+(notmuch-print-run-evince ps-file)))
+
+(defun notmuch-print-muttprint (msg)
+  "Print a message using muttprint."
+  (notmuch-print-run-muttprint))
+ 
+(defun notmuch-print-muttprint/evince (msg)
+  "Preview a message buffer using muttprint and evince."
+  (let ((ps-file (make-temp-file "notmuch")))
+(notmuch-print-run-muttprint (list "--printer" (concat "TO_FILE:" 
ps-file)))
+(notmuch-print-run-evince ps-file)))
+
+(defun notmuch-print-message (msg)
+  "Print a message using the user-selected mechanism."
+  (funcall notmuch-print-mechanism msg))
+
+(provide 'notmuch-print)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 797f94b..db25565 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -34,6 +34,7 @@
 (require 'notmuch-wash)
 (require 'notmuch-mua)
 (require 'notmuch-crypto)
+(require 'notmuch-print)

 (declare-function notmuch-call-notmuch-process "notmuch" ( args))
 (declare-function notmuch-fontify-headers "notmuch" nil)
@@ -186,6 +187,52 @@ indentation."
   mm-handle (> (notmuch-count-attachments mm-handle) 1
   (message "Done"))

+(defun notmuch-show-with-message-as-text (fn)
+  "Apply FN to a text representation of the current message.
+
+FN is called with one argument, the message 

[PATCH v3] Make buttons for attachments allow viewing as well as saving

[Antoine Beaupré]

On Tue, 17 Jan 2012 23:44:46 +, Mark Walters  
wrote:
> Define a keymap for attachment buttons to allow multiple actions.
> Define 3 possible actions:
> save attachment: exactly as currently,
> view attachment: uses mailcap entry,
> view attachment with user chosen program
> 
> Keymap on a button is: s for save, v for view and o for view with
> other program. Default (i.e. enter or mouse button) is save but this
> is configurable in notmuch customize.
> 
> One implementation detail: the view attachment function forces all
> attachments to be "displayed" using mailcap even if emacs could
> display them itself. Thus, for example, text/html appears in a browser
> and text/plain asks whether to save (on a standard debian setup)

This works pretty much as advertised, +1 from me, good work.

A.

-- 
C'est trop facile quand les guerres sont finies
D'aller gueuler que c'?tait la derni?re
Amis bourgeois vous me faites envie
Ne voyez vous pas donc point vos cimeti?res?
- Jaques Brel
-- 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/20120118/0083cda0/attachment.pgp>

on deleting messages

[Antoine Beaupré]

Hi Jamie!

I have taken the time to test those patches and those in the other
thread[1], and I like it! I was able to run all tests with the patches
applied and I am now running them alongside with most recent master
gd51b784 and Mark Walter's attachment buttons patch[2].

So I support those patches and hope they get in. The only issue I could
find was that I have the reflex of hitting A (capital a) instead of just
"a" in the search view because that's the key i hit in the show
view... but that's probably something i should get used to.

If something pops up I'll let you know!

A.

[1] id:"1325975294-646-2-git-send-email-jrollins at finestructure.net"
[2] id:"1326843886-18387-1-git-send-email-markwalters1009 at gmail.com"

-- 
Antoine Beaupr? +++ R?seau Koumbit Networks +++ +1.514.387.6262 #208

-- 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/20120118/c1ca05aa/attachment-0001.pgp>

[PATCH v2 4/5] emacs: Use the new JSON reply format.

[David Edmondson]

On Tue, 17 Jan 2012 15:53:37 -0700, Adam Wolfe Gordon <awg+notmuch at xvx.ca> 
wrote:
> +(defun notmuch-parts-filter-by-type (parts type)
> +  "Return a list of message parts with the given type"
> +  (let (result)
> +(dolist (part (append parts nil) result)
> +  (if (string= (cdr (assq 'content-type part)) type)
> +   (setq result (append result (list (cdr (assq 'content part)))
> +result))

I still think that `loop' is easier to read :-) But no objection to this
code.

> +(defun notmuch-mua-insert-part-quoted (part)
> +  (let ((start (point))
> + limit)
> +(insert part)
> +(setq limit (point))
> +(goto-char start)
> +(while (re-search-forward "\\(^\\)[^$]" limit 0)
> +  (replace-match "> " nil nil nil 1)
> +  ;; We have added two characters to the quotable region
> +  (setq limit (+ limit 2)))
> +(set-buffer-modified-p nil)))

You could use a marker for the limit, as it would then move along
automagically (sorry for not noticing this last time).
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/261935f8/attachment.pgp>

[PATCH 1/3] emacs: bind "s" to `notmuch-search' in notmuch-hello buffer

[Dmitry Kurochkin]

[of course I sent this email privately, sorry for duplicates]

On Tue, 17 Jan 2012 23:22:30 +0200, Jani Nikula  wrote:
> On Tue, 17 Jan 2012 23:34:08 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > Before the change, "s" in notmuch-hello buffer would jump to the
> > search box.  The patch changes the binding to `notmuch-search' which
> > is consistent with all other notmuch buffers.
> > ---
> >  emacs/notmuch-hello.el |   19 ++-
> >  1 files changed, 6 insertions(+), 13 deletions(-)
> > 
> > diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
> > index 02017ce..08fcd22 100644
> > --- a/emacs/notmuch-hello.el
> > +++ b/emacs/notmuch-hello.el
> > @@ -29,9 +29,6 @@
> >  (declare-function notmuch-search "notmuch" (query  oldest-first 
> > target-thread target-line continuation))
> >  (declare-function notmuch-poll "notmuch" ())
> >  
> > -(defvar notmuch-hello-search-bar-marker nil
> > -  "The position of the search bar within the notmuch-hello buffer.")
> > -
> >  (defcustom notmuch-recent-searches-max 10
> >"The number of recent searches to store and display."
> >:type 'integer
> > @@ -321,11 +318,6 @@ should be. Returns a cons cell `(tags-per-line 
> > width)'."
> > (widget-insert "\n"))
> >  found-target-pos))
> >  
> > -(defun notmuch-hello-goto-search ()
> > -  "Put point inside the `search' widget."
> > -  (interactive)
> > -  (goto-char notmuch-hello-search-bar-marker))
> 
> After this, what would the user have to do to bind some key to put the
> point in the search box? If someone wants to restore old behaviour for
> themselves.
> 

There is no way to do that.  From the previous discussions, I do not
remember anyone wanted the current "s" jumping behavior.  Let's wait for
some feedback and see if anyone wants that.  I would prefer to remove
this function and the global variable it uses.

> Also, it's perhaps out of scope for this patch, but it will become more
> evident now that notmuch-search does not respect
> notmuch-search-oldest-first when called without parameters like the new
> 's' keybinding does. This is the same in search view.
> 

I agree that this is an issue.  But it is outisde of the scope of this
patch series.

Regards,
  Dmitry

> 
> BR,
> Jani.
> 
> 
> > -
> >  (defimage notmuch-hello-logo ((:type png :file "notmuch-logo.png")))
> >  
> >  (defun notmuch-hello-search-continuation()
> > @@ -355,7 +347,7 @@ should be. Returns a cons cell `(tags-per-line width)'."
> >  (define-key map "G" 'notmuch-hello-poll-and-update)
> >  (define-key map (kbd "") 'widget-backward)
> >  (define-key map "m" 'notmuch-mua-new-mail)
> > -(define-key map "s" 'notmuch-hello-goto-search)
> > +(define-key map "s" 'notmuch-search)
> >  map)
> >"Keymap for \"notmuch hello\" buffers.")
> >  (fset 'notmuch-hello-mode-map notmuch-hello-mode-map)
> > @@ -468,7 +460,8 @@ Complete list of currently available key bindings:
> >(widget-insert " messages.\n"))
> >  
> >  (let ((found-target-pos nil)
> > - (final-target-pos nil))
> > + (final-target-pos nil)
> > + (search-bar-pos))
> >(let* ((saved-alist
> >   ;; Filter out empty saved searches if required.
> >   (if notmuch-show-empty-saved-searches
> > @@ -500,7 +493,7 @@ Complete list of currently available key bindings:
> > (indent-rigidly start (point) notmuch-hello-indent)))
> >  
> > (widget-insert "\nSearch: ")
> > -   (setq notmuch-hello-search-bar-marker (point-marker))
> > +   (setq search-bar-pos (point-marker))
> > (widget-create 'editable-field
> >;; Leave some space at the start and end of the
> >;; search boxes.
> > @@ -589,7 +582,7 @@ Complete list of currently available key bindings:
> > (when notmuch-saved-searches
> >   (widget-insert "Edit saved searches with the `edit' button.\n"))
> > (widget-insert "Hit RET or click on a saved search or tag name to view 
> > matching threads.\n")
> > -   (widget-insert "`=' refreshes this screen. `s' jumps to the search box. 
> > `q' to quit.\n")
> > +   (widget-insert "`=' refreshes this screen. `s' to search messages. `q' 
> > to quit.\n")
> > (let ((fill-column (- (window-width) notmuch-hello-indent)))
> >   (center-region start (point
> >  
> > @@ -601,7 +594,7 @@ Complete list of currently available key bindings:
> >   (widget-forward 1)))
> >  
> >(unless (widget-at)
> > -   (notmuch-hello-goto-search
> > +   (goto-char search-bar-pos
> >  
> >(run-hooks 'notmuch-hello-refresh-hook))
> >  
> > -- 
> > 1.7.8.3
> > 
> > ___
> > notmuch mailing list
> > notmuch at notmuchmail.org
> > http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v2 3/3] search: Support automatic tag exclusions

[Jameson Graef Rollins]

On Wed, 18 Jan 2012 08:38:23 +, David Edmondson  wrote:
> Something must create the initial configuration file if none exists. I'd
> be okay with that code adding 'deleted' and 'spam' to the excluded list.
>
> This would mean that an existing user would see no change without taking
> some action (adding the tags to the configuration file) and a new user
> would see the new behaviour (automatic exclusion).

What you describe is indeed how it currently works.  For new users or
old users who rerun setup, the config file will automatically include
the exclusions.  Otherwise, users will see no change.

> I'm not completely sure that automatically adding the exclusion of the
> specified tags via the configuration file for new users is a great
> idea. It seems as though it will lead to confusion for someone at some
> point.

Without any keys pre-bound to add "deleted" or "spam" tags, it probably
won't make much difference for new users.  And as long as it's
documented, users will be warned of the behavior.  Reading the config
file would also make it clear how the variable changes behavior.

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/20120118/907d6f30/attachment-0001.pgp>

[PATCH 4/6] emacs: add option to notmuch-show-next-open-message to pop out to parent buffer if at end

[Jameson Graef Rollins]

On Wed, 18 Jan 2012 08:12:27 +, David Edmondson  wrote:
> No need for brackets around `r'. Please put initialised local variables
> before uninitialised.

Yeah, that's another comment of Aron's that I forgot to fix this time
around.  Sorry about that.

> >  (while (and (setq r (notmuch-show-goto-message-next))
> > (not (notmuch-show-message-visible-p
> >  (if r
> > (progn
> >   (notmuch-show-mark-read)
> >   (notmuch-show-message-adjust))
> > -  (goto-char (point-max)
> > +  (if (and parent-buffer pop-at-end)
> > + (progn
> > +   (kill-this-buffer)
> > +   (switch-to-buffer parent-buffer)
> > +   (forward-line 1))
> > +   (goto-char (point-max))
> 
> Can you explain in words how this is expected to behave please?

If there is not another message, but there is a parent buffer and the
pop-at-end variable is set, kill this buffer, go the parent, and move to
the next thread.  Otherwise, go to the max point in the buffer.

Do you see a problem?

The one thing I do realize now is that the behavior might be slightly
strange if the parent buffer is itself a show buffer.  In that case, the
forward-line part doesn't make any sense.  It should check that the
parent is a search buffer first.  It should also use the notmuch-search
function to jump to the next thread (notmuch-search-next-thread).  The
notmuch-show-next-thread function could use the same improvements.

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/20120118/9423fcd1/attachment.pgp>

[PATCH v3] Make buttons for attachments allow viewing as well as saving

[Mark Walters]

> Oof, sorry.  Two more tweaks that I really should have caught in the
> previous version.  After that this gets my automatic +1.

Both fixed. I have also fixed the bug I mentioned (missing filename when
"view" falls back on save); I couldn't make it work with the
"no-default" option. However overriding mm-save-part with flet seems to
do the trick.

+(defun notmuch-show-view-part (message-id nth  filename content-type )
+  (notmuch-with-temp-part-buffer message-id nth
+;; set mm-inlined-types to nil to force an external viewer
+(let ((handle (mm-make-handle (current-buffer) (list content-type)))
+ (mm-inlined-types nil))
+  ;; We override mm-save-part as notmuch-show-save-part is better
+  ;; since it offers the filename
+  (flet ((mm-save-part ( args) (ignore)))
+   (or (mm-display-part handle)
+   (notmuch-show-save-part message-id nth filename 
content-type))

Is that a reasonable solution? 

Best wishes

Mark

Improving notmuch query documentation [was: Re: Partial words on notmuch search?]

[Andrei Popescu]

On Lu, 16 ian 12, 21:34:31, Austin Clements wrote:
> Quoth Andrei Popescu on Jan 16 at 10:21 pm:
> > This is also interesting:
> > $ notmuch count 'debian'
> > 65888
> > $ notmuch count 'dEbian'
> > 65888
> > $ notmuch count 'Debian'
> > 65887
> 
> The first two will match stemmed versions of "debian" such as
> "debian's" and "debianed".  However, starting a term with a capital
> letter suppresses stemming (because it suggests that it's a name,
> which you wouldn't want to modify), so your last query matches only
> the term "debian".  This is probably documented somewhere, though I
> don't know where.

Stemming is mentioned in the Xapian docs, but I didn't understand the 
meaning until I read your explanation, thanks :)

> > Where can I read more about this? (except the source :)
> 
> Most of this is in the Xapian query syntax document you found.  Really
> we ought to beef-up Notmuch's query syntax documentation.

If I get around to write something myself where do you suggest I should 
start, the wiki or the manpage?

Thanks,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120118/d4b267ff/attachment.pgp>

[PATCH] emacs: Improved printing support.

[David Edmondson]

Add various functions to print notmuch messages and tie them together
with a simple frontend.

Add a binding ('#') in `notmuch-show-mode' to print the current
message.
---

Updates based on Aaron's review - the comments were very useful in
improving things - thanks!

Add a keybinding to `notmuch-show-mode'.

 emacs/Makefile.local   |3 +-
 emacs/notmuch-print.el |   85 
 emacs/notmuch-show.el  |   53 ++
 3 files changed, 140 insertions(+), 1 deletions(-)
 create mode 100644 emacs/notmuch-print.el

diff --git a/emacs/Makefile.local b/emacs/Makefile.local
index 0c58b82..4fee0e8 100644
--- a/emacs/Makefile.local
+++ b/emacs/Makefile.local
@@ -13,7 +13,8 @@ emacs_sources := \
$(dir)/notmuch-maildir-fcc.el \
$(dir)/notmuch-message.el \
$(dir)/notmuch-crypto.el \
-   $(dir)/coolj.el
+   $(dir)/coolj.el \
+   $(dir)/notmuch-print.el
 
 emacs_images := \
$(srcdir)/$(dir)/notmuch-logo.png
diff --git a/emacs/notmuch-print.el b/emacs/notmuch-print.el
new file mode 100644
index 000..77f10bb
--- /dev/null
+++ b/emacs/notmuch-print.el
@@ -0,0 +1,85 @@
+;; notmuch-print.el --- printing messages from notmuch.
+;;
+;; Copyright © David Edmondson
+;;
+;; This file is part of Notmuch.
+;;
+;; Notmuch is free software: you can redistribute it and/or modify it
+;; under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+;;
+;; Notmuch is distributed in the hope that it will be useful, but
+;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+;; General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with Notmuch.  If not, see http://www.gnu.org/licenses/.
+;;
+;; Authors: David Edmondson d...@dme.org
+
+(defcustom notmuch-print-mechanism 'notmuch-print-lpr
+  How should printing be done?
+  :group 'notmuch
+  :type '(choice
+ (function :tag Use lpr notmuch-print-lpr)
+ (function :tag Use ps-print notmuch-print-ps-print)
+ (function :tag Use ps-print then evince 
notmuch-print-ps-print/evince)
+ (function :tag Use muttprint notmuch-print-muttprint)
+ (function :tag Use muttprint then evince 
notmuch-print-muttprint/evince)
+ (function :tag Using a custom function)))
+
+;; Utility functions:
+
+(defun notmuch-print-run-evince (file)
+  View FILE using 'evince'.
+  (start-process evince nil evince file))
+
+(defun notmuch-print-run-muttprint (optional output)
+  Pass the contents of the current buffer to 'muttprint'.
+
+Optional OUTPUT allows passing a list of flags to muttprint.
+  (apply #'call-process-region (point-min) (point-max)
+;; Reads from stdin.
+muttprint
+nil nil nil
+;; Show the tags.
+--printed-headers Date_To_From_CC_Newsgroups_*Subject*_/Tags/
+output))
+
+;; User-visible functions:
+
+(defun notmuch-print-lpr (msg)
+  Print a message buffer using lpr.
+  (lpr-buffer))
+
+(defun notmuch-print-ps-print (msg)
+  Print a message buffer using the ps-print package.
+  (let ((subject (plist-get (notmuch-show-get-prop :headers msg) :Subject)))
+(rename-buffer subject t)
+(ps-print-buffer)))
+
+(defun notmuch-print-ps-print/evince (msg)
+  Preview a message buffer using ps-print and evince.
+  (let ((ps-file (make-temp-file notmuch))
+   (subject (plist-get (notmuch-show-get-prop :headers msg) :Subject)))
+(rename-buffer subject t)
+(ps-print-buffer ps-file)
+(notmuch-print-run-evince ps-file)))
+
+(defun notmuch-print-muttprint (msg)
+  Print a message using muttprint.
+  (notmuch-print-run-muttprint))
+ 
+(defun notmuch-print-muttprint/evince (msg)
+  Preview a message buffer using muttprint and evince.
+  (let ((ps-file (make-temp-file notmuch)))
+(notmuch-print-run-muttprint (list --printer (concat TO_FILE: 
ps-file)))
+(notmuch-print-run-evince ps-file)))
+
+(defun notmuch-print-message (msg)
+  Print a message using the user-selected mechanism.
+  (funcall notmuch-print-mechanism msg))
+
+(provide 'notmuch-print)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 797f94b..db25565 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -34,6 +34,7 @@
 (require 'notmuch-wash)
 (require 'notmuch-mua)
 (require 'notmuch-crypto)
+(require 'notmuch-print)
 
 (declare-function notmuch-call-notmuch-process notmuch (rest args))
 (declare-function notmuch-fontify-headers notmuch nil)
@@ -186,6 +187,52 @@ indentation.
   mm-handle ( (notmuch-count-attachments mm-handle) 1
   (message Done))
 
+(defun notmuch-show-with-message-as-text (fn)
+  Apply FN to a text representation of the current message.
+
+FN is called with one argument, the message properties. It should
+operation on 

Re: [PATCH 1/6] emacs: break up notmuch-show-archive-thread-internal into two generally useful functions

[David Edmondson]

Very happy with the overall ideas.

On Tue, 17 Jan 2012 10:05:26 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 -(defun notmuch-show-archive-thread-internal (show-next)
 -  ;; Remove the tag from the current set of messages.
 +(defun notmuch-show-tag-thread-internal (tag optional remove)
 +  ;; Add tag to the current set of messages.  If the remove switch is
 +  ;; given, tags will be removed instead of added.
(goto-char (point-min))
 -  (loop do (notmuch-show-remove-tag inbox)
 - until (not (notmuch-show-goto-message-next)))
 -  ;; Move to the next item in the search results, if any.
 +  (let ((tag-function 'notmuch-show-add-tag))
 +(if remove
 + (setq tag-function 'notmuch-show-remove-tag))

This seems odd. How about:

 (let ((tag-function (if remove 'notmuch-show-remove-tag 
'notmuch-show-add-tag)))
  ...

 +(loop do (funcall tag-function tag)
 +   until (not (notmuch-show-goto-message-next)

Otherwise good.


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

Re: [PATCH 2/6] emacs: break out thread navigation from notmuch-show-archive-thread

[David Edmondson]

+1.


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

Re: [PATCH 3/6] emacs: add message archiving functions

[David Edmondson]

+1.


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

Re: [PATCH 4/6] emacs: add option to notmuch-show-next-open-message to pop out to parent buffer if at end

[David Edmondson]

On Tue, 17 Jan 2012 10:05:29 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 -(defun notmuch-show-next-open-message ()
 +(defun notmuch-show-next-open-message (optional pop-at-end)
Show the next message.
(interactive)
 -  (let (r)
 +  (let ((r)
 + (parent-buffer notmuch-show-parent-buffer))

No need for brackets around `r'. Please put initialised local variables
before uninitialised.

  (while (and (setq r (notmuch-show-goto-message-next))
   (not (notmuch-show-message-visible-p
  (if r
   (progn
 (notmuch-show-mark-read)
 (notmuch-show-message-adjust))
 -  (goto-char (point-max)
 +  (if (and parent-buffer pop-at-end)
 +   (progn
 + (kill-this-buffer)
 + (switch-to-buffer parent-buffer)
 + (forward-line 1))
 + (goto-char (point-max))

Can you explain in words how this is expected to behave please?


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

Re: [PATCH 6/6] emacs: modify the default show-mode key bindings for archiving

[David Edmondson]

+1.


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

Re: [PATCH 1/6] emacs: break up notmuch-show-archive-thread-internal into two generally useful functions

[David Edmondson]

On Tue, 17 Jan 2012 12:17:54 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Tue, 17 Jan 2012 15:10:40 -0500, Aaron Ecay aarone...@gmail.com wrote:
  This should be a docstring instead of a comment.  (This applies equally
  to the old version)
 
 We're not currently in the habit of adding doc strings for
 non-interactive programs.  Do we need to go down that route?

They are nice to have, especially if we already have the comment.


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

Re: [PATCH v2 2/2] Add pseudo-compatibility with gmime 2.6

[Tomi Ollila]

On Tue, 17 Jan 2012 17:25:46 -0500, Austin Clements amdra...@mit.edu wrote:
 Quoth Thomas Jost on Jan 17 at 11:50 am:
   
  +#ifdef GMIME_26
  +/* sig_list may be created in both above cases, so we need to
  + * cleanly handle it here. */
  +if (node-sig_list) {
  +   GMimeSignatureList **proxy =
  +   talloc (node, GMimeSignatureList *);
 
 This doesn't need to be split into two lines.
 
  +   *proxy = node-sig_list;
  +   talloc_set_destructor (proxy, _signature_list_free);
  +}
  +#else
   if (node-verify_attempted  !node-sig_validity)
  fprintf (stderr, Failed to verify signed part: %s\n,
   (err ? err-message : no error explanation given));
  +#endif
 
 I'd rather see the above as a separate #ifdef GMIME_26 and #ifndef
 GMIME_26, since they aren't logical alternates of each other.

That reminds me that it should then be like GMIME_ATLEAST_26, so
that this might be useful when GMIME  2.6 is available...

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

Re: on deleting messages

[David Edmondson]

Add the bindings. Provide documentation that makes it clear that they
just add tags and never delete anything.


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

Re: [PATCH 1/3] emacs: bind s to `notmuch-search' in notmuch-hello buffer

[David Edmondson]

Looks fine.


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

Re: [PATCH 2/3] emacs: use a single history for all searches

[David Edmondson]

On Tue, 17 Jan 2012 23:34:09 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:
 There are two ways to do search in Emacs UI: search widget in
 notmuch-hello buffer and `notmuch-search' function bound to s.
 Before the change, these search mechanisms used different history
 lists.  The patch makes notmuch-hello search use the same history list
 as `notmuch-search' function.

The test output updates included here should be with the previous patch,
shouldn't they?

 -(defun notmuch-search (query optional oldest-first target-thread 
 target-line continuation)
 -  Run \notmuch search\ with the given query string and display results.
 +(defun notmuch-search (optional query oldest-first target-thread 
 target-line continuation)
 +  Run \notmuch search\ with the given `query' and display results.
  
 -The optional parameters are used as follows:
 +If `query' is nil, it is read interactively from the minibuffer.
 +Other optional parameters are used as follows:
  
oldest-first: A Boolean controlling the sort order of returned threads
target-thread: A thread ID (with the thread: prefix) that will be made
   current if it appears in the search results.
target-line: The line number to move to if the target thread does not
 appear in the search results.
 -  (interactive (list (notmuch-read-query Notmuch search: )))
 +  (interactive)
 +  (if (null query)
 +  (setq query (notmuch-read-query Notmuch search: ))
 +(setq query (notmuch-trim query))
 +(let ((history-delete-duplicates t))
 +  (add-to-history 'notmuch-search-history query)))

Should user-typed queries be trimmed?


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