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

[David Bremner]

On Thu,  5 Jan 2012 22:25:12 +0200, Jani Nikula  wrote:
> notmuch_show_params_t params is only initialized partially in
> notmuch_reply_command(). The only field that is used uninitialized is
> params.decrypt. It is usually non-zero, making "notmuch reply" on encrypted
> messages work by coincidence.

Hi Jani;

I get one test failure with this patch on current master:

 FAIL   Reply within emacs
--- emacs.24.expected   2012-01-07 03:47:50.0 +
+++ emacs.24.output 2012-01-07 03:47:50.0 +
@@ -1,5 +1,5 @@
 From: Notmuch Test Suite 
-To: user at example.com
+To: 
 Subject: Re: Testing message sent via SMTP
 In-Reply-To: 
 Fcc: /tmp/notmuch-dev-bremner/test/tmp.emacs/mail/sent

d

[PATCH] run notmuch-hello-mode-hook at the end of the hello mode setup

[Jani Nikula]

Hi, looks like a similar patch has been applied as commit
db352df09e92171293eacf159342cd950ae596d0.

BR,
Jani.


On Mon,  8 Aug 2011 12:26:58 +0200, Antoine Beaupr?  
wrote:
> i mostly use this to start offlineimap.el, but it could be used for
> other purposes. i have not added hooks to other modes, but those could
> be interesting as well. i am unsure as to how to make unit tests for
> this.
> ---
>  emacs/notmuch-hello.el |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
> index 65fde75..6389ac8 100644
> --- a/emacs/notmuch-hello.el
> +++ b/emacs/notmuch-hello.el
> @@ -118,6 +118,11 @@ Typically \",\" in the US and UK and \".\" in Europe."
>:group 'notmuch
>:type 'string)
>  
> +(defcustom notmuch-hello-mode-hook nil
> +  "Hook run at the end of `notmuch-hello-mode'."
> +  :group 'notmuch
> +  :type 'hook)
> +
>  (defvar notmuch-hello-url "http://notmuchmail.org;
>"The `notmuch' web site.")
>  
> @@ -336,6 +341,7 @@ Complete list of currently available key bindings:
>   (setq major-mode 'notmuch-hello-mode
> mode-name "notmuch-hello")
>   ;;(setq buffer-read-only t)
> + (run-mode-hooks 'notmuch-hello-mode 'notmuch-hello-mode-hook)
>  )
>  
>  (defun notmuch-hello-generate-tag-alist ()
> -- 
> 1.7.2.5
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 1/2] add notmuch keybinding 'd'

[Tomi Ollila]

On Fri, 06 Jan 2012 15:10:57 -0500, Antoine Beaupr?  
wrote:
> 
> For the curious, those (other) patches are:
> 
>  * lib: add 'safe' setting for flags
>  * lib: Add back the synchronization of 'T' flag with deleted tag
>  * run notmuch-hello-mode-hook at the end of the hello mode setup

To add other replies, there are now notmuch-hello-mode-hook and
notmuch-hello-refresh-hook impmelented.

> Most of those do not change the current behavior, and I have been
> running them for more than 4 months.
> 
> I'd very much like to get help to get this in... 
> 
> A.

Tomi

[PATCH 1/2] add notmuch keybinding 'd'

[Jani Nikula]

Hi Antoine -

On Fri, 06 Jan 2012 15:10:57 -0500, Antoine Beaupr?  
wrote:
> On Tue, 03 Jan 2012 21:57:22 +0200, Jani Nikula  wrote:
> > I wouldn't use it either, and I don't use "deleted" tag in the first
> > place. And even if I used it, I'd still like to keep the distinction
> > between "deleted after reading" and "deleted unread", which this patch
> > loses by removing the "unread" tag.
> 
> I have been using this for months now.
> 
> But honestly, I don't care much anymore: the hard part is not the tag,
> it's what you do with it after (hint: just remove the damn file).
> 
> Most patches I have submitted here haven't been accepted and I have to
> painfully reroll my own packages every time there's a new release, which
> has been a very frustrating experience. To see such a trivial patch
> obsoleted tops it.

This patch, while trivial, fixes a specific use case for you, according
to your preferences. I was hoping for something more generic, and
Jameson showed how this can be done in one's .emacs without adding new
code (or carrying your own patches) at all. If this approach does not
work for you, please let us know why!

> For the curious, those (other) patches are:
> 
>  * lib: add 'safe' setting for flags
>  * lib: Add back the synchronization of 'T' flag with deleted tag
>  * run notmuch-hello-mode-hook at the end of the hello mode setup
> 
> Most of those do not change the current behavior, and I have been
> running them for more than 4 months.

I haven't looked at the patches, but please understand that not changing
the current behaviour is not a sufficient reason for inclusion. Once in,
people will start using the features, which will need to be maintained
and supported potentially for a very long time. Once in, it's not easy
to take features out. Especially so for lib. So we need to be careful.

Tests have also become an increasingly important part in getting any
non-trivial changes in. It's not enough that they work perfectly now; we
need to be able to make sure later changes won't break them.

> I'd very much like to get help to get this in... 

I'll try to find a moment to review your other patches.

I've also had my moments of frustration, but things have really improved
significantly since you've sent those patches. David is doing an
excellent job. Be persistent!


Kind regards,
Jani.

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

[Tomi Ollila]

On Thu, 05 Jan 2012 22:58:30 +0200, Jani Nikula  wrote:
> On Thu, 05 Jan 2012 12:38:18 -0800, Jameson Graef Rollins  finestructure.net> wrote:
> > On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula  wrote:
> > > In the search view it does exactly this.
> > 
> > I worry about race conditions in this case, though.  I frequently
> > archive threads after I've read everything, but I still want to know if
> > new message to that thread come in.  If I attempt to archive a thread in
> > notmuch-search, but a new message has entered the thread without me
> > knowing it, I'll archive the new message before I had a chance to look
> > at it.
> 
> Just to be clear: The patch in question does not alter this
> behaviour. The race you describe is there already.
> 
> And at a glance, it does not look like something that would be trivial
> to fix. The buffer does not have the information to do that.

Hmm, I currently run 'notmuch new' from command line... I've been thinking
changing that but now knowing this issue I think I'm not going to do that...


> BR,
> Jani.

Tomi

[PATCH] emacs: Mark the quoted region during reply.

[Tomi Ollila]

On Fri,  6 Jan 2012 10:03:40 +, David Edmondson  wrote:
> Mark the quoted region of text during a reply, making it easy for the
> user to delete it quickly.
> ---

+1

Tomi

>  emacs/notmuch-mua.el |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
> index 7114e48..32e2e30 100644
> --- a/emacs/notmuch-mua.el
> +++ b/emacs/notmuch-mua.el
> @@ -108,7 +108,8 @@ list."
>  (if (re-search-backward message-signature-separator nil t)
> (forward-line -1)
>(goto-char (point-max)))
> -(insert body))
> +(insert body)
> +(push-mark))
>(set-buffer-modified-p nil)
>  
>(message-goto-body))
> -- 
> 1.7.7.3

[PATCH] emacs: Mark the quoted region during reply.

[Xavier Maillard]

On Fri,  6 Jan 2012 10:03:40 +, David Edmondson  wrote:
> Mark the quoted region of text during a reply, making it easy for the
> user to delete it quickly.

LGTM ! (That's also a desirable feature).

/Xavier

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Thomas Jost]

On Sun, 25 Dec 2011 23:54:41 -0500, Aaron Ecay  wrote:
> On Thu, 15 Dec 2011 19:50:36 -0400, David Bremner  
> wrote:
> > I think the problem is related to emacsclient.
> > 
> > With 'm' I have the following behaviour:
> > 
> > emacs -q --daemon
> > M-x notmuch (to load variable definitions)
> > M-x customize-variable notmuch-mua-compose-in
> > (select compose in new window, save for current session)
> > M-x notmuch
> > m   ;; new window is opened as it should be
> > C-c C-c ;; frame is closed.
> 
> I just tried, and I cannot reproduce this behavior.  IIUC, here is what
> happened to you: you set nm-mua-compose-in to 'new-window.  You began a
> new message, this opened a new window as expected.  Your emacs frame now
> has two windows in it.  You sent this message, which deleted the window
> showing it.  Your emacs frame was deleted as well, which made the other
> window, showing notmuch-hello (or some other notmuch buffer, from which
> you began writing the email message) disappear as well, unexpectedly.
> Is this a correct description of what happened?
> 
> Here?s the recipe I used for replicating:
> 
> emacs -q --daemon
> emacsclient -c
> C-x b *scratch*
> (add-to-list 'load-path "/path/to/notmuch/emacs/") C-j
> (load-library "notmuch") C-j
> C-x C-f /path/to/notmuch/emacs/notmuch-mua.el
> M-x eval-buffer (in order to pick up changes not in byte-compiled file)
> M-x customize-variable notmuch-mua-compose-in (set to 'new-window, save for 
> session)
> M-x notmuch
> m (new window is created in current frame, below the window showing 
> notmuch-hello)
> (type mail)
> C-c C-c (enter smtp settings, since emacs doesn?t know them)
> (new window disappears, the window with notmuch-hello fills whole frame)

I've used something like this (+setting message-send-mail-function,
sendmail-program, sendmail extra arguments, message-signature and
notmuch-fcc-dirs) and done the following tests:
- Emacs 23.3 vs Emacs 24.0.92 (23.3 from Arch [extra] repo, 24.0.92
  compiled from AUR emacs-pretest package)
- with and without --daemon
- setting message-kill-buffer-on-exit to nil and t

In every case, the new mail composition window opened correctly next to
the notmuch-hello window. Here is what I got after successfully sending
a test mail in every situation:

- when message-kill-buffer-on-exit is "t":
  * E23: mail buffer killed, window closed, frame still there (OK)
  * E23 daemon: same thing (OK)
  * E24: same thing (OK)
  * E24 daemon: same thing (OK)

- when message-kill-buffer-on-exit is "nil":
  * E23: mail buffer buried, window still there, frame still there
  * E23 daemon: frame was killed after sending. When restarting
emacsclient: buffer buried but still there
  * E24: mail buffer buried, window closed, frame still there (OK)
  * E24 daemon: same thing (OK)

So basically everything works as expected when mkboe is "t", and there
are issues with Emacs 23 when mkboe is "nil".

I'm very sorry for these issues, I should have done more testing with
mkboe set to "nil", and I don't think I tested Emacs 23 at all with the
latest versions of this patch. I'll try to fix that and post a new patch
in a few days.

Best regards,

-- 
Thomas/Schnouki
------ next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120106/1449754d/attachment.pgp>

[RFC][PATCH] emacs: Use text properties rather than overlays in various places.

[David Edmondson]

On Fri, 06 Jan 2012 08:58:31 -0800, Jameson Graef Rollins  wrote:
> On Wed, 28 Dec 2011 14:31:31 +, David Edmondson  wrote:
> > Probably just for aficionados at the moment...
> 
> Actually, I think that all the rest of these comments should be included
> in the log.  There's useful discussion here.

Okay.

The work-in-progress `notmuch-mode' patches that Austin posted to lazily
construct the invisible overlays suggests a way that could be integrated
with these changes to further improve performance, but I haven't had
time to look at it yet.

> > Given that clashes between overlays and text properties are a problem
> > and overlays are considered expensive, switching to text properties
> > makes sense. For example, the coloured tags in the headerline are back
> > with this patch.
> 
> I actually currently have colored tags in the headerline.  Did they go
> somewhere at some point?

I haven't looked properly, but I think that emacs 24 stole them. They
certainly were not updating correctly during the addition/removal of
tags.
-- 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/20120106/fc8c6118/attachment.pgp>

[PATCH 1/2] add notmuch keybinding 'd'

[David Bremner]

On Fri, 06 Jan 2012 15:10:57 -0500, Antoine Beaupr?  
wrote:
> On Tue, 03 Jan 2012 21:57:22 +0200, Jani Nikula  wrote:

>  * lib: add 'safe' setting for flags
>  * lib: Add back the synchronization of 'T' flag with deleted tag
>  * run notmuch-hello-mode-hook at the end of the hello mode setup

> 
> Most of those do not change the current behavior, and I have been
> running them for more than 4 months.
> 
> I'd very much like to get help to get this in... 

Hi Antoine;

I understand your frustration; it's not very motivating to feel
ignored. Over the last few months we have been working to develop a
patch review process for notmuch [1], but as you can see from [2] there
is still a backlog of patches that have not been reviewed, the two lib
patches you mention among them. More reviewers are always welcome ;).

David

[1]: http://notmuchmail.org/nmbug/
[2]: http://nmbug.tethera.net/status/

[PATCH] Perform mail polling asynchronously

[David Edmondson]

On Fri, 06 Jan 2012 06:45:59 -0800, Jesse Rosenthal  
wrote:
> On Tue, 03 Jan 2012 16:02:43 +, David Edmondson  wrote:
> > On Mon,  5 Sep 2011 07:14:36 +0300, Antono Vasiljev  
> > wrote:
> >
> > If the poll script runs asynchronously, won't the notmuch-search output
> > refresh and jump into my face when I'm busy doing something else? And,
> > if I'm not busy doing something else, why can't I just wait for the poll
> > script to complete?
> 
> Well, he might have dropped it (and notmuch), but I've been wondering
> about the possibilities of this for the emacs client. What I was
> imagining was some sort of modeline notifier, like what ERC offers. It
> could easily alert you without jumping into your face.

It sounds useful, but that patch is not 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/20120106/235851e2/attachment-0001.pgp>

[PATCH 1/2] add notmuch keybinding 'd'

[Antoine Beaupré]

On Tue, 03 Jan 2012 21:57:22 +0200, Jani Nikula  wrote:
> I wouldn't use it either, and I don't use "deleted" tag in the first
> place. And even if I used it, I'd still like to keep the distinction
> between "deleted after reading" and "deleted unread", which this patch
> loses by removing the "unread" tag.

I have been using this for months now.

But honestly, I don't care much anymore: the hard part is not the tag,
it's what you do with it after (hint: just remove the damn file).

Most patches I have submitted here haven't been accepted and I have to
painfully reroll my own packages every time there's a new release, which
has been a very frustrating experience. To see such a trivial patch
obsoleted tops it.

For the curious, those (other) patches are:

 * lib: add 'safe' setting for flags
 * lib: Add back the synchronization of 'T' flag with deleted tag
 * run notmuch-hello-mode-hook at the end of the hello mode setup

Most of those do not change the current behavior, and I have been
running them for more than 4 months.

I'd very much like to get help to get this in... 

A.
-- 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/20120106/8fb6af40/attachment.pgp>

[PATCH 0/4] notmuch reply bugfix & reply to sender only

[Jani Nikula]

Hi Mark -

On Thu, 05 Jan 2012 22:01:30 +, Mark Walters  
wrote:
> > Bikeshedding topic #1: How about making replying to just the sender the 
> > default
> > in "notmuch reply", and having --reply-all option (instead of 
> > --no-reply-all)?
> 
> In id:"87pqn5cg4g.fsf at yoom.home.cworth.org" cworth suggested using
> --reply-to=sender vs. --reply-to=all (keeping the latter the default).

That is a sound proposal too, leaving room for extension if such need
might arise.

> However, one more significant choice is what to do on reply-to-sender to
> an email from the user himself. My patch used the following logic: look
> at the reply-to, from , to, cc lines until you find a non-user address
> and use that line for the reply. My recollection is that this is roughly
> what mutt does.

That is a very good point, and one that my patch fails to address.

> (*) I have a version of that patch-set which applies to master if that
> would be useful to anyone, and I recently started writing tests in
> preparation for re-submitting.

Ah, it's old, no wonder I didn't know about it. Looking at the v2 of it
that I found gmane, it looks like the approach is roughly the same.

I think me passing the 'add' parameter makes things a bit more obvious
and explicit, while your use of "g_mime_message_get_all_recipients
(reply) == NULL" might be more robust (including handling reply to
user's own message). Switching to new style argument parsing is probably
something David will insist on, and that's a ready, independent patch in
my set. On emacs side I think my patch is just slightly cleaner, but no
big difference.

How about you post what you have now as a reply to this thread, and let
others be the judge? I really don't mind whether it's you or I who
finishes this as long as we get the feature, and preferrably combining
the best of what we both have. I'm also open to splitting this between
you and me; just let me know what you think.


BR,
Jani.

[PATCH 0/4] notmuch reply bugfix & reply to sender only

[Mark Walters]

Hello

I have now compared the two patch sets. They seem very similar but I
think yours is a little bit nicer in all respects except I prefer my
use of "g_mime_message_get_all_recipients (reply) == NULL".

However, one case that is slightly less clear with my approach is
what to do about reply-to-thread (or indeed any reply to more than one
message). I did not add a reply-to-thread not_all option as I wasn't
sure what it should do. Perhaps we could even make reply-to-one return
an error if the search gives more than one message? 

Best wishes

Mark

[PATCH] Perform mail polling asynchronously

[Antono Vasiljev]

On Tue, 2012-01-03 at 16:02 +, David Edmondson wrote:

> On Mon,  5 Sep 2011 07:14:36 +0300, Antono Vasiljev  
> wrote:
> >   * reimplemented notmuch-poll( callback) so that it
> > calls process asynchronously and run callback after process
> > finished
> >   * changed usage of notmuch-poll in notmuch-hello-poll-and-update
> > and notmuch-search-poll-and-refresh-view
> 
> I don't understand the real purpose of this patch.

> If the poll script runs asynchronously, won't the notmuch-search output
> refresh and jump into my face when I'm busy doing something else? And,
> if I'm not busy doing something else, why can't I just wait for the poll
> script to complete?

Sync io sucks.
Just drop it if you do not like. I don't use notmuch anymore so i dont
care.

[PATCH 4/4] add tests for reply-to-sender

[Mark Walters]

---
 test/notmuch-test|1 +
 test/reply-to-sender |  209 ++
 2 files changed, 210 insertions(+), 0 deletions(-)
 create mode 100755 test/reply-to-sender

diff --git a/test/notmuch-test b/test/notmuch-test
index e40ef86..6a99ae3 100755
--- a/test/notmuch-test
+++ b/test/notmuch-test
@@ -33,6 +33,7 @@ TESTS="
   thread-naming
   raw
   reply
+  reply-to-sender
   dump-restore
   uuencode
   thread-order
diff --git a/test/reply-to-sender b/test/reply-to-sender
new file mode 100755
index 000..c7d15bb
--- /dev/null
+++ b/test/reply-to-sender
@@ -0,0 +1,209 @@
+#!/usr/bin/env bash
+test_description="\"notmuch reply --reply-to=sender\" in several variations"
+. ./test-lib.sh
+
+test_begin_subtest "Basic reply-to-sender"
+add_message '[from]="Sender "' \
+ [to]=test_suite at notmuchmail.org \
+ [subject]=notmuch-reply-test \
+'[date]="Tue, 05 Jan 2010 15:43:56 -"' \
+'[body]="basic reply-to-sender test"'
+
+output=$(notmuch reply --reply-to=sender id:${gen_msg_id})
+test_expect_equal "$output" "From: Notmuch Test Suite 
+Subject: Re: notmuch-reply-test
+To: Sender 
+In-Reply-To: <${gen_msg_id}>
+References: <${gen_msg_id}>
+
+On Tue, 05 Jan 2010 15:43:56 -, Sender  wrote:
+> basic reply-to-sender test"
+
+test_begin_subtest "From Us, Basic reply to message"
+add_message '[from]="Notmuch Test Suite "' \
+'[to]="Recipient "' \
+ [subject]=notmuch-reply-test \
+'[date]="Tue, 05 Jan 2010 15:43:56 -"' \
+'[body]="basic reply-to-from-us test"'
+
+output=$(notmuch reply --reply-to=sender id:${gen_msg_id})
+test_expect_equal "$output" "From: Notmuch Test Suite 
+Subject: Re: notmuch-reply-test
+To: Recipient 
+In-Reply-To: <${gen_msg_id}>
+References: <${gen_msg_id}>
+
+On Tue, 05 Jan 2010 15:43:56 -, Notmuch Test Suite  wrote:
+> basic reply-to-from-us test"
+
+test_begin_subtest "Multiple recipients"
+add_message '[from]="Sender "' \
+'[to]="test_suite at notmuchmail.org, Someone Else "' \
+ [subject]=notmuch-reply-test \
+'[date]="Tue, 05 Jan 2010 15:43:56 -"' \
+'[body]="Multiple recipients"'
+
+output=$(notmuch reply  --reply-to=sender  id:${gen_msg_id})
+test_expect_equal "$output" "From: Notmuch Test Suite 
+Subject: Re: notmuch-reply-test
+To: Sender 
+In-Reply-To: <${gen_msg_id}>
+References: <${gen_msg_id}>
+
+On Tue, 05 Jan 2010 15:43:56 -, Sender  wrote:
+> Multiple recipients"
+
+test_begin_subtest "From Us, Multiple TO recipients"
+add_message '[from]="Notmuch Test Suite "' \
+'[to]="Recipient , Someone Else "' \
+ [subject]=notmuch-reply-test \
+'[date]="Tue, 05 Jan 2010 15:43:56 -"' \
+'[body]="From Us, Multiple TO recipients"'
+
+output=$(notmuch reply  --reply-to=sender  id:${gen_msg_id})
+test_expect_equal "$output" "From: Notmuch Test Suite 
+Subject: Re: notmuch-reply-test
+To: Recipient , Someone Else 
+In-Reply-To: <${gen_msg_id}>
+References: <${gen_msg_id}>
+
+On Tue, 05 Jan 2010 15:43:56 -, Notmuch Test Suite  wrote:
+> From Us, Multiple TO recipients"
+
+test_begin_subtest "Reply with CC"
+add_message '[from]="Sender "' \
+ [to]=test_suite at notmuchmail.org \
+'[cc]="Other Parties "' \
+ [subject]=notmuch-reply-test \
+'[date]="Tue, 05 Jan 2010 15:43:56 -"' \
+'[body]="reply with CC"'
+
+output=$(notmuch reply  --reply-to=sender id:${gen_msg_id})
+test_expect_equal "$output" "From: Notmuch Test Suite 
+Subject: Re: notmuch-reply-test
+To: Sender 
+In-Reply-To: <${gen_msg_id}>
+References: <${gen_msg_id}>
+
+On Tue, 05 Jan 2010 15:43:56 -, Sender  wrote:
+> reply with CC"
+
+test_begin_subtest "From Us, Reply with CC"
+add_message '[from]="Notmuch Test Suite "' \
+'[to]="Recipient "' \
+'[cc]="Other Parties "' \
+ [subject]=notmuch-reply-test \
+'[date]="Tue, 05 Jan 2010 15:43:56 -"' \
+'[body]="reply with CC"'
+
+output=$(notmuch reply  --reply-to=sender id:${gen_msg_id})
+test_expect_equal "$output" "From: Notmuch Test Suite 
+Subject: Re: notmuch-reply-test
+To: Recipient 
+In-Reply-To: <${gen_msg_id}>
+References: <${gen_msg_id}>
+
+On Tue, 05 Jan 2010 15:43:56 -, Notmuch Test Suite  wrote:
+> reply with CC"
+
+test_begin_subtest "From Us, Reply no TO but with CC"
+add_message '[from]="Notmuch Test Suite "' \
+'[cc]="Other Parties "' \
+ [subject]=notmuch-reply-test \
+'[date]="Tue, 05 Jan 2010 15:43:56 -"' \
+'[body]="reply with CC"'
+
+output=$(notmuch reply  --reply-to=sender id:${gen_msg_id})
+test_expect_equal "$output" "From: Notmuch Test Suite 
+Subject: Re: notmuch-reply-test
+Cc: Other Parties 
+In-Reply-To: <${gen_msg_id}>
+References: <${gen_msg_id}>
+
+On Tue, 05 Jan 2010 15:43:56 -, Notmuch Test Suite  wrote:
+> 

[PATCH 3/4] Emacs changes for reply-to-sender

[Mark Walters]

Reply to sender is currently bound to R
---
 emacs/notmuch-mua.el  |8 +---
 emacs/notmuch-show.el |8 +++-
 emacs/notmuch.el  |2 +-
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 7114e48..7171210 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -71,12 +71,14 @@ list."
(push header message-hidden-headers)))
notmuch-mua-hidden-headers))

-(defun notmuch-mua-reply (query-string  sender)
+(defun notmuch-mua-reply (query-string option-string  sender)
   (let (headers
body
(args '("reply")))
 (if notmuch-show-process-crypto
(setq args (append args '("--decrypt"
+(if option-string
+   (setq args (append args (list option-string
 (setq args (append args (list query-string)))
 ;; This make assumptions about the output of `notmuch reply', but
 ;; really only that the headers come first followed by a blank
@@ -217,13 +219,13 @@ the From: address first."
(notmuch-mua-forward-message))
 (notmuch-mua-forward-message)))

-(defun notmuch-mua-new-reply (query-string  prompt-for-sender)
+(defun notmuch-mua-new-reply (query-string option-string  
prompt-for-sender)
   "Invoke the notmuch reply window."
   (interactive "P")
   (let ((sender
 (when prompt-for-sender
   (notmuch-mua-prompt-for-sender
-(notmuch-mua-reply query-string sender)))
+(notmuch-mua-reply query-string option-string sender)))

 (defun notmuch-mua-send-and-exit ( arg)
   (interactive "P")
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 5502efd..40bea0c 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -933,6 +933,7 @@ thread id.  If a prefix is given, crypto processing is 
toggled."
(define-key map "m" 'notmuch-mua-new-mail)
(define-key map "f" 'notmuch-show-forward-message)
(define-key map "r" 'notmuch-show-reply)
+   (define-key map "R" 'notmuch-show-reply-sender)
(define-key map "|" 'notmuch-show-pipe-message)
(define-key map "w" 'notmuch-show-save-attachments)
(define-key map "V" 'notmuch-show-view-raw-message)
@@ -1239,7 +1240,12 @@ any effects from previous calls to
 (defun notmuch-show-reply ( prompt-for-sender)
   "Reply to the current message."
   (interactive "P")
-  (notmuch-mua-new-reply (notmuch-show-get-message-id) prompt-for-sender))
+  (notmuch-mua-new-reply (notmuch-show-get-message-id) nil prompt-for-sender))
+
+(defun notmuch-show-reply-sender ( prompt-for-sender)
+  "Reply to the current message but only to sender."
+  (interactive "P")
+  (notmuch-mua-new-reply (notmuch-show-get-message-id) "--reply-to=sender" 
prompt-for-sender))

 (defun notmuch-show-forward-message ( prompt-for-sender)
   "Forward the current message."
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index fde2377..022b867 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -444,7 +444,7 @@ Complete list of currently available key bindings:
   "Begin composing a reply to the entire current thread in a new buffer."
   (interactive "P")
   (let ((message-id (notmuch-search-find-thread-id)))
-(notmuch-mua-new-reply message-id prompt-for-sender)))
+(notmuch-mua-new-reply message-id nil prompt-for-sender)))

 (defun notmuch-call-notmuch-process ( args)
   "Synchronously invoke \"notmuch\" with the given list of arguments.
-- 
1.7.2.3

[PATCH 2/4] Update the man page for notmuch-reply to give the syntax for the --reply-to option.

[Mark Walters]

---
 man/man1/notmuch-reply.1 |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/man/man1/notmuch-reply.1 b/man/man1/notmuch-reply.1
index 099d808..13cc72c 100644
--- a/man/man1/notmuch-reply.1
+++ b/man/man1/notmuch-reply.1
@@ -45,6 +45,19 @@ Includes subject and quoted message body.
 Only produces In\-Reply\-To, References, To, Cc, and Bcc headers.
 .RE
 .RE
+.RS
+.TP 4
+.BR \-\-reply\-to= ( sender | all )
+.RS
+.TP 4
+.BR sender
+Replies only to the sender (or to all addresses in the To header if
+the sending address is one of the user's email addresses).
+.TP
+.BR all " (default)"
+Replies to all addresses.
+.RE
+.RE

 See \fBnotmuch-search-terms\fR(7)
 for details of the supported syntax for .
-- 
1.7.2.3

[PATCH 1/4] Add the option "--reply-to" to notmuch reply.

[Mark Walters]

Possible values for this option are "sender" which replies just to
sender and "all" (the default).

More precisely reply to sender follows these rules:
reply only to sender unless it was the user
reply only to all people on the "to" line unless they were all the user
reply to all people on the "cc" line

Implementation details

We continue parsing addresses beyond the ones we reply to because
we want to make sure the from address is correct. (At the very least it
is the same as it would be if we replied to all.)

We overload the message variable in add_recipients_for_address_list so
if it is NULL we parse the address (looking for the users address)
but do not add to the message recipients list

We add the variable reply_to_all to the function chain to keep track
of whether we should reply to everyone.
---
 notmuch-reply.c |   48 +---
 1 files changed, 37 insertions(+), 11 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index f8d5f64..9a77fe6 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -212,7 +212,8 @@ add_recipients_for_address_list (GMimeMessage *message,
if (ret == NULL)
ret = addr;
} else {
-   g_mime_message_add_recipient (message, type, name, addr);
+if (message)
+ g_mime_message_add_recipient (message, type, name, addr);
}
}
 }
@@ -292,7 +293,8 @@ reply_to_header_is_redundant (notmuch_message_t *message)
 static const char *
 add_recipients_from_message (GMimeMessage *reply,
 notmuch_config_t *config,
-notmuch_message_t *message)
+notmuch_message_t *message,
+int reply_to_all)
 {
 struct {
const char *header;
@@ -332,9 +334,20 @@ add_recipients_from_message (GMimeMessage *reply,
recipients = notmuch_message_get_header (message,
 reply_to_map[i].fallback);

-   addr = add_recipients_for_string (reply, config,
- reply_to_map[i].recipient_type,
- recipients);
+
+   /* We add the addresses if we are replying to all or we have not yet 
found
+* a non-user address. We have to keep parsing to make sure we do find 
the
+* correct from address for the user, but we pass a NULL message
+*/
+   if ((reply_to_all) || (g_mime_message_get_all_recipients (reply) == 
NULL))
+   addr = add_recipients_for_string (reply, config,
+ reply_to_map[i].recipient_type,
+ recipients);
+   else
+addr = add_recipients_for_string (NULL, config,
+  reply_to_map[i].recipient_type,
+  recipients);
+
if (from_addr == NULL)
from_addr = addr;
 }
@@ -480,7 +493,8 @@ static int
 notmuch_reply_format_default(void *ctx,
 notmuch_config_t *config,
 notmuch_query_t *query,
-notmuch_show_params_t *params)
+notmuch_show_params_t *params,
+int reply_to_all)
 {
 GMimeMessage *reply;
 notmuch_messages_t *messages;
@@ -509,7 +523,7 @@ notmuch_reply_format_default(void *ctx,
g_mime_message_set_subject (reply, subject);
}

-   from_addr = add_recipients_from_message (reply, config, message);
+   from_addr = add_recipients_from_message (reply, config, message, 
reply_to_all);

if (from_addr == NULL)
from_addr = guess_from_received_header (config, message);
@@ -558,7 +572,8 @@ static int
 notmuch_reply_format_headers_only(void *ctx,
  notmuch_config_t *config,
  notmuch_query_t *query,
- unused (notmuch_show_params_t *params))
+ unused (notmuch_show_params_t *params),
+ int reply_to_all)
 {
 GMimeMessage *reply;
 notmuch_messages_t *messages;
@@ -598,7 +613,7 @@ notmuch_reply_format_headers_only(void *ctx,
g_mime_object_set_header (GMIME_OBJECT (reply),
  "References", references);

-   (void)add_recipients_from_message (reply, config, message);
+   (void)add_recipients_from_message (reply, config, message, 
reply_to_all);

reply_headers = g_mime_object_to_string (GMIME_OBJECT (reply));
printf ("%s", reply_headers);
@@ -620,7 +635,8 @@ notmuch_reply_command (void *ctx, int argc, char *argv[])
 notmuch_query_t *query;
 char *opt, *query_string;
 int i, ret = 0;

[PATCH 0/4] notmuch reply bugfix & reply to sender only

[Mark Walters]

> That is a very good point, and one that my patch fails to address.
> 
> > (*) I have a version of that patch-set which applies to master if that
> > would be useful to anyone, and I recently started writing tests in
> > preparation for re-submitting.
> 
> Ah, it's old, no wonder I didn't know about it. Looking at the v2 of it
> that I found gmane, it looks like the approach is roughly the same.
> 
> I think me passing the 'add' parameter makes things a bit more obvious
> and explicit, while your use of "g_mime_message_get_all_recipients
> (reply) == NULL" might be more robust (including handling reply to
> user's own message). Switching to new style argument parsing is probably
> something David will insist on, and that's a ready, independent patch in
> my set. On emacs side I think my patch is just slightly cleaner, but no
> big difference.

I have not had a chance to look at your code yet: I will try to do so
this afternoon.

> How about you post what you have now as a reply to this thread, and let
> others be the judge? I really don't mind whether it's you or I who
> finishes this as long as we get the feature, and preferrably combining
> the best of what we both have. I'm also open to splitting this between
> you and me; just let me know what you think.

I will post it as a reply to this message. I don't mind which version
goes in either (but it would  be nice if some version did!)

Best wishes

Mark

[PATCH 1/2] add notmuch keybinding 'd'

[Jameson Graef Rollins]

On Fri, 06 Jan 2012 15:10:57 -0500, Antoine Beaupr?  
wrote:
> Most patches I have submitted here haven't been accepted and I have to
> painfully reroll my own packages every time there's a new release, which
> has been a very frustrating experience. To see such a trivial patch
> obsoleted tops it.

Don't be too over dramatic, Antoine.  A lot of patches have sat fallow
for a long time, and a lot of us maintain our own stuff on top what's in
master.

There's also been discussion on this particular topic since long before
you showed up.  cworth pushed back on adding a delete key until we had a
more integrated solution.  I think the same thing is happening here.

I'm going to take a crack at an implementation of this functionality
this weekend that I think will satisfy most of out needs.

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/20120106/8d55ef64/attachment.pgp>

[PATCH] Perform mail polling asynchronously

[David Edmondson]

On Fri, 06 Jan 2012 14:09:57 +0300, Antono Vasiljev  wrote:
> On Tue, 2012-01-03 at 16:02 +, David Edmondson wrote:
> 
> > On Mon,  5 Sep 2011 07:14:36 +0300, Antono Vasiljev  
> > wrote:
> > >   * reimplemented notmuch-poll( callback) so that it
> > > calls process asynchronously and run callback after process
> > > finished
> > >   * changed usage of notmuch-poll in notmuch-hello-poll-and-update
> > > and notmuch-search-poll-and-refresh-view
> > 
> > I don't understand the real purpose of this patch.
> 
> > If the poll script runs asynchronously, won't the notmuch-search output
> > refresh and jump into my face when I'm busy doing something else? And,
> > if I'm not busy doing something else, why can't I just wait for the poll
> > script to complete?
> 
> Sync io sucks.
> Just drop it if you do not like. I don't use notmuch anymore so i dont
> care.

Antono, thanks for replying. I'll mark the patch as 'obsolete'.
-- 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/20120106/f5c5f8b2/attachment.pgp>

Exporting mime email

[David Edmondson]

On Fri, 06 Jan 2012 10:51:47 +, Mark Walters  
wrote:
> > Presumably something is converting it from 8bit to base64 along the
> > path.
> 
> If it makes a difference my setup is gmail->offlineimap->notmuch

Mine is the same for the relevant messages.

> > I scouted around for other messages that include ?? (which is what I
> > presume causes the encoding), but the ones I have are all still 8bit.
> 
> A different example which shows the same problem (for me) is
> id:"m2fwg1uapw.fsf at gmail.com"

This one is encoded as quoted-printable. I agree that the output of
 | cat >/tmp/file
in the emacs UI produces the encoded file and that it is identical to
the file on disk.

Hence, I can reproduce the problem you reported :-)

(Maybe amusingly) the printing stuff that you originally mentioned
included some code to produce a 'text' version of a message for
printing. Maybe that could also be used to implement a simple
`notmuch-show-save-message' command?
-- 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/20120106/d0edeeb4/attachment.pgp>

Exporting mime email

[Mark Walters]

Hi

> Presumably something is converting it from 8bit to base64 along the
> path.

If it makes a difference my setup is gmail->offlineimap->notmuch

> I scouted around for other messages that include ?? (which is what I
> presume causes the encoding), but the ones I have are all still 8bit.

A different example which shows the same problem (for me) is
id:"m2fwg1uapw.fsf at gmail.com"

Many thanks

Mark

Exporting mime email

[David Edmondson]

On Fri, 06 Jan 2012 10:27:16 +, Mark Walters  
wrote:
> Does saving the message like this give you a file you can apply directly
> with the patch command? When I save it (using | or from view-raw) I get
> a message which looks like

Ahh. This particular message is a bad example for me to check, because I
have the version that I bcc'd rather than the one delivered by the
mailing list.

Presumably something is converting it from 8bit to base64 along the
path.

I scouted around for other messages that include ? (which is what I
presume causes the encoding), but the ones I have are all still 8bit.

> I have just discovered git am which solves this problem for patches but
> I think it might be useful to be able to export the plain-text email
> sometimes.

Agreed.
-- 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/20120106/6c895bf3/attachment.pgp>

Exporting mime email

[Mark Walters]

Hello

On Fri, 06 Jan 2012 08:35:27 +, David Edmondson  wrote:
> On Fri, 06 Jan 2012 00:29:39 +, Mark Walters  gmail.com> wrote:
> > What is the best way of exporting/saving as text a mime-encoded email
> > from the emacs interface (e.g, if I want to save a mime-encoded email
> > containing a patch)?
> > 
> > For non-mime emails View-raw is fine, but with mime encoded emails such
> > as (picked pretty much at random)
> > id:"1325240897-27525-1-git-send-email-dme at dme.org"
> > I haven't found any non-hack method.
> 
> That message is 8bit UTF-8 at my end. Saving it use '|' works just fine
> for me. What encoding do you see?

Does saving the message like this give you a file you can apply directly
with the patch command? When I save it (using | or from view-raw) I get
a message which looks like

(Delivery headers)
From: ...
To: ...
Subject: =?UTF-8?q?=5BPATCH=5D=20emacs=3A=20Improved=20printing=20support=2E?=
Date: ..
(some X and list headers)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: notmuch-bounces at notmuchmail.org
Errors-To: notmuch-bounces at notmuchmail.org

QWRkIHZhcmlvdXMgZnVuY3Rpb25zIHRvIHByaW50IG5vdG11Y2ggbWVzc2FnZXMgYW5kIHRpZSB0
aGVtIHRvZ2V0aGVyCndpdGggYSBzaW1wbGUgZnJvbnRlbmQuIE5vIGtleWJpbmRpbmcgaXMgY3Vy
cmVudGx5IG1hZGUgdG8gZW5jb3VyYWdlCnBhcGVyIHNhdmluZy4KLS0tCgpSZXN1cnJlY3Rpbmcg
.. for 100 lines or so

The saved file is identical to the file  in my maildir. But feeding it
to patch in the form  patch -p1 < exported_file does not work.

I have just discovered git am which solves this problem for patches but
I think it might be useful to be able to export the plain-text email
sometimes.

(If this is all some messed up utf-8 settings my end then many apologies
for the noise)

Many thanks 

Mark

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

[Jani Nikula]

On Thu, 05 Jan 2012 23:22:34 -0400, David Bremner  wrote:
> On Thu,  5 Jan 2012 22:25:12 +0200, Jani Nikula  wrote:
> > -notmuch_show_params_t params;
> > +notmuch_show_params_t params = { .part = -1 };
> >  
> >  reply_format_func = notmuch_reply_format_default;
> > -params.part = -1;
> 
> Do I understand correctly that this is just a style change, or do you
> rely on some c99(?) behaviour of initializing the other elements to 0?

It is not just a style change, and initializing a struct partially
initializes the rest of the elements to 0. That's not C99 specific
behaviour, though using the designated initializer to initialize .part
to -1 is.

All of these result in the same value for params:

notmuch_show_params_t params = { .part = -1 };

notmuch_show_params_t params = { 0, 0, -1 };

notmuch_show_params_t params = { 0, 0, -1, NULL, 0 };

notmuch_show_params_t params = { 0 };
params.part = -1;

IMHO the first is cleanest and unaffected by changes in
notmuch_show_params_t, though might be surprising if you're not (yet)
used to C99 designated initializers.

In any case, in the current implementation only .part and .cryptoctx are
initialized, and the rest of the fields are random. This needs to be
fixed one way or another.


BR,
Jani.

[PATCH] emacs: Mark the quoted region during reply.

[David Edmondson]

Mark the quoted region of text during a reply, making it easy for the
user to delete it quickly.
---
 emacs/notmuch-mua.el |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 7114e48..32e2e30 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -108,7 +108,8 @@ list."
 (if (re-search-backward message-signature-separator nil t)
  (forward-line -1)
   (goto-char (point-max)))
-(insert body))
+(insert body)
+(push-mark))
   (set-buffer-modified-p nil)

   (message-goto-body))
-- 
1.7.7.3

[PATCH v2] emacs: Helpers for notmuch developers.

[David Edmondson]

---

- Prefix the branch name with 'review/'
- Avoid `shell-command', which also results in better error reporting
  when 'git-am' fails.

 emacs/notmuch-dev.el |  129 ++
 1 files changed, 129 insertions(+), 0 deletions(-)
 create mode 100644 emacs/notmuch-dev.el

diff --git a/emacs/notmuch-dev.el b/emacs/notmuch-dev.el
new file mode 100644
index 000..ac427ec
--- /dev/null
+++ b/emacs/notmuch-dev.el
@@ -0,0 +1,129 @@
+;; notmuch-dev.el --- help for notmuch developers
+;;
+;; 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 
+
+(require 'notmuch-lib)
+(require 'notmuch-show)
+(require 'magit)
+
+(defgroup notmuch-dev nil
+  "Helpers for notmuch developers."
+  :group 'notmuch)
+
+(defcustom notmuch-dev-master-repository "git://notmuchmail.org/git/notmuch"
+  "The URI of the master notmuch repository."
+  :group 'notmuch-dev
+  :type 'string)
+
+(defcustom notmuch-dev-temporary-directory temporary-file-directory
+  "A directory in which to place temporary repositories."
+  :group 'notmuch-dev
+  :type 'string)
+
+;;
+
+(defvar notmuch-dev-temporary-repository-name (concat "notmuch-dev-" 
(user-login-name))
+  "The name of the temporary repository.")
+
+(defvar notmuch-dev-temporary-repository-path
+  (file-name-as-directory (file-truename (concat 
notmuch-dev-temporary-directory "/"
+
notmuch-dev-temporary-repository-name)))
+  "The path of the temporary repository.")
+
+(defun notmuch-dev-make-temporary-repository ()
+  (unless (file-directory-p notmuch-dev-temporary-repository-path)
+(message "Cloning %s into %s..." 
+notmuch-dev-master-repository 
notmuch-dev-temporary-repository-path)
+(magit-run* (list magit-git-executable "clone"
+ notmuch-dev-master-repository
+ notmuch-dev-temporary-repository-path))
+(message "Cloning %s into %s...done." 
+notmuch-dev-master-repository 
notmuch-dev-temporary-repository-path)
+
+(unless (file-directory-p notmuch-dev-temporary-repository-path)
+  (error "git clone failed."
+
+(defun notmuch-dev-checkout-master ()
+  (magit-checkout "master"))
+
+(defun notmuch-dev-delete-branch (name)
+  (magit-delete-branch name))
+
+(defun notmuch-dev-create-branch (name)
+  ;; Switches to the new branch automatically.
+  (magit-create-branch name "master"))
+
+(defun notmuch-dev-flatten-title (title)
+  (let* ((s (downcase title))
+(s (replace-regexp-in-string "[ \t/]+" "-" s))
+(s (replace-regexp-in-string "[\]\[\":]" "" s))
+(s (replace-regexp-in-string "\\.$" "" s))
+)
+s))
+
+(defun notmuch-dev-title-to-branch (title)
+  (concat "review/" (notmuch-dev-flatten-title title)))
+
+(defun notmuch-dev-title-to-mbox (title)
+  (concat notmuch-dev-temporary-directory "/"
+ (notmuch-dev-flatten-title title) ".mbox"))
+
+;;
+
+(defun notmuch-dev-show-review-patch ()
+  "Call this from `notmuch-show-mode'."
+  (interactive)
+
+  (notmuch-dev-review-patch (notmuch-show-get-subject)
+   (mapconcat 'identity
+  
(notmuch-show-get-message-ids-for-open-messages)
+  " OR ")))
+
+(defun notmuch-dev-review-patch (title search-terms)
+  (let ((patch-name (notmuch-dev-title-to-branch title))
+   (mbox-path (notmuch-dev-title-to-mbox title)))
+
+(notmuch-dev-make-temporary-repository)
+
+;; Switch to the repository directory.
+(let ((default-directory notmuch-dev-temporary-repository-path))
+
+  (notmuch-dev-checkout-master)
+  ;; Delete the branch if it exists.
+  (condition-case nil
+ (notmuch-dev-delete-branch patch-name)
+   (error nil))
+  (notmuch-dev-create-branch patch-name)
+
+  ;; Have notmuch generate mailbox format output for the search
+  ;; terms...
+  (with-temp-file mbox-path
+   (erase-buffer)
+   (call-process notmuch-command nil t nil
+ "show" "--format=mbox" search-terms))
+
+  ;; ...and feed that to git-am.
+  (magit-run* (list magit-git-executable "am" mbox-path))
+
+  (magit-status notmuch-dev-temporary-repository-path
+
+;;
+
+(provide 'notmuch-dev)
-- 
1.7.7.3

[PATCH 2/2] test: Add tests for advance/rewind.

[Jameson Graef Rollins]

On Thu, 29 Dec 2011 16:05:39 +, David Edmondson  wrote:
> What's the general feeling about this approach to producing tests for
> the emacs UI? (That is, code the test in a .el file and call the
> relevant function(s) from the test harness.)

I think it's a nice idea.  It seems much cleaner than writing ever more
complicated code in the command line.  There was another recent idea to
actually write the python tests in python, if I remember correctly.  It
all seems to make sense to me.  Bash is convenient, but there's no
reason we need to be monogamous, especially when there are ways, with
your technique, to call individual "embedded" tests from the command
line and still take advantage of the bells and whistles of full test
infrastructure.

> It makes it simpler to develop and maintain the test (because you can do
> more work with traditional emacs support for editing elisp), but might
> make interpreting failures more difficult (the test harness mostly just
> reports 'failed').

It is really nice to see diffs on failure, actually, to get a sense of
what exactly went wrong.  Is it possible to have some sort of standard
report to stdout that could provide more info?

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/20120106/47e8b664/attachment.pgp>

[RFC][PATCH] emacs: Use text properties rather than overlays in various places.

[Jameson Graef Rollins]

On Wed, 28 Dec 2011 14:31:31 +, David Edmondson  wrote:
> Probably just for aficionados at the moment...

Actually, I think that all the rest of these comments should be included
in the log.  There's useful discussion here.

> Given that clashes between overlays and text properties are a problem
> and overlays are considered expensive, switching to text properties
> makes sense. For example, the coloured tags in the headerline are back
> with this patch.

I actually currently have colored tags in the headerline.  Did they go
somewhere at some point?

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/20120106/41e8fde6/attachment.pgp>

[PATCH 0/4] notmuch reply bugfix & reply to sender only

[David Edmondson]

On Thu,  5 Jan 2012 22:25:11 +0200, Jani Nikula  wrote:
> Bikeshedding topic #1: How about making replying to just the sender the 
> default
> in "notmuch reply", and having --reply-all option (instead of --no-reply-all)?

No strong opinion (I hardly ever use the CLI directly).

> Bikeshedding topic #2: How about binding 'r' to reply to just the sender by
> default, and making 'R' reply-all (instead of vice versa)?

I'd be happy with that.
-- 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/20120106/5e57f5bc/attachment-0001.pgp>

Exporting mime email

[David Edmondson]

On Fri, 06 Jan 2012 00:29:39 +, Mark Walters  
wrote:
> What is the best way of exporting/saving as text a mime-encoded email
> from the emacs interface (e.g, if I want to save a mime-encoded email
> containing a patch)?
> 
> For non-mime emails View-raw is fine, but with mime encoded emails such
> as (picked pretty much at random)
> id:"1325240897-27525-1-git-send-email-dme at dme.org"
> I haven't found any non-hack method.

That message is 8bit UTF-8 at my end. Saving it use '|' works just fine
for me. What encoding do you see?

(And you should use id:"1325599946-5936-1-git-send-email-dme at dme.org"
instead :-))
-- 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/20120106/94de68fe/attachment.pgp>

[PATCH] emacs: Helpers for notmuch developers.

[David Edmondson]

On Thu, 05 Jan 2012 23:39:30 -0400, David Bremner  wrote:
> > General management (i.e. keeping up to date) of the repository it uses
> > is your responsibility, as is cleaning out old branches. You can, of
> > course, just delete the temporary repository after using it - the code
> > will re-create it next time.
> 
> maybe the branches could be under some namespace that makes this easy?

Just a prefix? 'review/' or something?

> > +(defvar notmuch-dev-temporary-repository-name (concat "notmuch-dev-" 
> > (user-login-name))
> > +  "The name of the temporary repository.")
> 
> Do we care about security at all in this context? I'm always a bit
> nervous about creating predictably named files/directories in publicly
> writable places.

I presume that you'd already have set `temporary-file-directory' if you
worry about this generally, or `notmuch-dev-temporary-directory' if just
in this instance.

> > +  ;; Causes us to switch to the magit buffer - is that unfortunate in
> > +  ;; some situations?
> > +  (magit-status notmuch-dev-temporary-repository-path))
> 
> I found it to be a pleasant surprise.

Ending there when the whole sequence completes, I agree. The question is
really about whether displaying the magit-status buffer after simply
creating the repository is good.

> > +  (shell-command
> > +   (concat
> > +   notmuch-command " show --format=mbox " (shell-quote-argument 
> > search-terms)
> > +   " | "
> > +   "git am --quiet"))
> > +
> 
> Hmm. A knee jerk reaction is not to like this, like seeing system in C
> code. But I don't have a better solution off hand.

Agreed. I think that I'll split it into two parts:
  - running notmuch to create a mailbox (or perhaps directory of
patches),
  - running git-am to apply the patches.

A bigger problem is that magit appears to be ignorant of git-am, with
the result that if applying the patches fails magit doesn't provide any
help (or even notification) that there are outstanding things to do. It
also blocks a future git-am.

Currently thinking about an alternative to using git-am that is more
magit friendly...
-- 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/20120106/d2339bce/attachment.pgp>

[PATCH] NEWS: consistent 2-space indentation

[David Bremner]

On Wed,  4 Jan 2012 15:26:52 +0200, Tomi Ollila  wrote:
> ---
> This patch is submitted on release branch.
>  NEWS |   16 
>  1 files changed, 8 insertions(+), 8 deletions(-)

Hi Tomi;

It seems like applying this to release is just asking for trouble. It is
already quite an ordeal merging patches for NEWS. Is there some urgency
for this in terms of supporting automated posting of NEWS to the wiki?

d

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

[David Bremner]

On Fri, 06 Jan 2012 10:11:42 +0200, Jani Nikula  wrote:

> IMHO the first is cleanest and unaffected by changes in
> notmuch_show_params_t, though might be surprising if you're not (yet)
> used to C99 designated initializers.

Obviously not ;). It would nice to have a consensus about the use of C99
features in the notmuch code. Personally I think it's fine, but I know
we have had some back and forth about e.g. mid-block variable declarations.

> In any case, in the current implementation only .part and .cryptoctx are
> initialized, and the rest of the fields are random. This needs to be
> fixed one way or another.

Agreed.

d

[PATCH] Perform mail polling asynchronously

[Jesse Rosenthal]

On Tue, 03 Jan 2012 16:02:43 +, David Edmondson  wrote:
> On Mon,  5 Sep 2011 07:14:36 +0300, Antono Vasiljev  
> wrote:
>
> If the poll script runs asynchronously, won't the notmuch-search output
> refresh and jump into my face when I'm busy doing something else? And,
> if I'm not busy doing something else, why can't I just wait for the poll
> script to complete?

Well, he might have dropped it (and notmuch), but I've been wondering
about the possibilities of this for the emacs client. What I was
imagining was some sort of modeline notifier, like what ERC offers. It
could easily alert you without jumping into your face.

Just musing -- I haven't had time to actually think it all the way
through.

--J

Exporting mime email

[Mark Walters]

Hi

On Thu, 05 Jan 2012 16:44:10 -0800, Jameson Graef Rollins  wrote:
> On Fri, 06 Jan 2012 00:29:39 +, Mark Walters  gmail.com> wrote:
> > What is the best way of exporting/saving as text a mime-encoded email
> > from the emacs interface (e.g, if I want to save a mime-encoded
> > email containing a patch)?
> 
> Maybe you're looking for '|'?  That will pipe the raw message to
> whatever command is specified.

What I would like is a way of exporting the decoded text rather than the
raw message. As an explicit example I would like to be able to export a
mime encoded email containing a patch, and then do something like

patch -p1 < exported_file

Sorry for not making myself clear

Many thanks

Mark

Exporting mime email

[Mark Walters]

Hello

What is the best way of exporting/saving as text a mime-encoded email
from the emacs interface (e.g, if I want to save a mime-encoded
email containing a patch)?

For non-mime emails View-raw is fine, but with mime encoded emails such
as (picked pretty much at random)
id:"1325240897-27525-1-git-send-email-dme at dme.org"
I haven't found any non-hack method.

Many thanks

Mark

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

[Jani Nikula]

On Thu, 05 Jan 2012 23:22:34 -0400, David Bremner da...@tethera.net wrote:
 On Thu,  5 Jan 2012 22:25:12 +0200, Jani Nikula j...@nikula.org wrote:
  -notmuch_show_params_t params;
  +notmuch_show_params_t params = { .part = -1 };
   
   reply_format_func = notmuch_reply_format_default;
  -params.part = -1;
 
 Do I understand correctly that this is just a style change, or do you
 rely on some c99(?) behaviour of initializing the other elements to 0?

It is not just a style change, and initializing a struct partially
initializes the rest of the elements to 0. That's not C99 specific
behaviour, though using the designated initializer to initialize .part
to -1 is.

All of these result in the same value for params:

notmuch_show_params_t params = { .part = -1 };

notmuch_show_params_t params = { 0, 0, -1 };

notmuch_show_params_t params = { 0, 0, -1, NULL, 0 };

notmuch_show_params_t params = { 0 };
params.part = -1;

IMHO the first is cleanest and unaffected by changes in
notmuch_show_params_t, though might be surprising if you're not (yet)
used to C99 designated initializers.

In any case, in the current implementation only .part and .cryptoctx are
initialized, and the rest of the fields are random. This needs to be
fixed one way or another.


BR,
Jani.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: Helpers for notmuch developers.

[David Edmondson]

On Thu, 05 Jan 2012 23:39:30 -0400, David Bremner da...@tethera.net wrote:
  General management (i.e. keeping up to date) of the repository it uses
  is your responsibility, as is cleaning out old branches. You can, of
  course, just delete the temporary repository after using it - the code
  will re-create it next time.
 
 maybe the branches could be under some namespace that makes this easy?

Just a prefix? 'review/' or something?

  +(defvar notmuch-dev-temporary-repository-name (concat notmuch-dev- 
  (user-login-name))
  +  The name of the temporary repository.)
 
 Do we care about security at all in this context? I'm always a bit
 nervous about creating predictably named files/directories in publicly
 writable places.

I presume that you'd already have set `temporary-file-directory' if you
worry about this generally, or `notmuch-dev-temporary-directory' if just
in this instance.

  +  ;; Causes us to switch to the magit buffer - is that unfortunate in
  +  ;; some situations?
  +  (magit-status notmuch-dev-temporary-repository-path))
 
 I found it to be a pleasant surprise.

Ending there when the whole sequence completes, I agree. The question is
really about whether displaying the magit-status buffer after simply
creating the repository is good.

  +  (shell-command
  +   (concat
  +   notmuch-command  show --format=mbox  (shell-quote-argument 
  search-terms)
  +| 
  +   git am --quiet))
  +
 
 Hmm. A knee jerk reaction is not to like this, like seeing system in C
 code. But I don't have a better solution off hand.

Agreed. I think that I'll split it into two parts:
  - running notmuch to create a mailbox (or perhaps directory of
patches),
  - running git-am to apply the patches.

A bigger problem is that magit appears to be ignorant of git-am, with
the result that if applying the patches fails magit doesn't provide any
help (or even notification) that there are outstanding things to do. It
also blocks a future git-am.

Currently thinking about an alternative to using git-am that is more
magit friendly...


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

Re: Exporting mime email

[David Edmondson]

On Fri, 06 Jan 2012 00:29:39 +, Mark Walters markwalters1...@gmail.com 
wrote:
 What is the best way of exporting/saving as text a mime-encoded email
 from the emacs interface (e.g, if I want to save a mime-encoded email
 containing a patch)?
 
 For non-mime emails View-raw is fine, but with mime encoded emails such
 as (picked pretty much at random)
 id:1325240897-27525-1-git-send-email-...@dme.org
 I haven't found any non-hack method.

That message is 8bit UTF-8 at my end. Saving it use '|' works just fine
for me. What encoding do you see?

(And you should use id:1325599946-5936-1-git-send-email-...@dme.org
instead :-))


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

Re: [PATCH 0/4] notmuch reply bugfix reply to sender only

[David Edmondson]

On Thu,  5 Jan 2012 22:25:11 +0200, Jani Nikula j...@nikula.org wrote:
 Bikeshedding topic #1: How about making replying to just the sender the 
 default
 in notmuch reply, and having --reply-all option (instead of --no-reply-all)?

No strong opinion (I hardly ever use the CLI directly).

 Bikeshedding topic #2: How about binding 'r' to reply to just the sender by
 default, and making 'R' reply-all (instead of vice versa)?

I'd be happy with that.


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

[PATCH v2] emacs: Helpers for notmuch developers.

[David Edmondson]

---

- Prefix the branch name with 'review/'
- Avoid `shell-command', which also results in better error reporting
  when 'git-am' fails.

 emacs/notmuch-dev.el |  129 ++
 1 files changed, 129 insertions(+), 0 deletions(-)
 create mode 100644 emacs/notmuch-dev.el

diff --git a/emacs/notmuch-dev.el b/emacs/notmuch-dev.el
new file mode 100644
index 000..ac427ec
--- /dev/null
+++ b/emacs/notmuch-dev.el
@@ -0,0 +1,129 @@
+;; notmuch-dev.el --- help for notmuch developers
+;;
+;; 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
+
+(require 'notmuch-lib)
+(require 'notmuch-show)
+(require 'magit)
+
+(defgroup notmuch-dev nil
+  Helpers for notmuch developers.
+  :group 'notmuch)
+
+(defcustom notmuch-dev-master-repository git://notmuchmail.org/git/notmuch
+  The URI of the master notmuch repository.
+  :group 'notmuch-dev
+  :type 'string)
+
+(defcustom notmuch-dev-temporary-directory temporary-file-directory
+  A directory in which to place temporary repositories.
+  :group 'notmuch-dev
+  :type 'string)
+
+;;
+
+(defvar notmuch-dev-temporary-repository-name (concat notmuch-dev- 
(user-login-name))
+  The name of the temporary repository.)
+
+(defvar notmuch-dev-temporary-repository-path
+  (file-name-as-directory (file-truename (concat 
notmuch-dev-temporary-directory /
+
notmuch-dev-temporary-repository-name)))
+  The path of the temporary repository.)
+
+(defun notmuch-dev-make-temporary-repository ()
+  (unless (file-directory-p notmuch-dev-temporary-repository-path)
+(message Cloning %s into %s... 
+notmuch-dev-master-repository 
notmuch-dev-temporary-repository-path)
+(magit-run* (list magit-git-executable clone
+ notmuch-dev-master-repository
+ notmuch-dev-temporary-repository-path))
+(message Cloning %s into %s...done. 
+notmuch-dev-master-repository 
notmuch-dev-temporary-repository-path)
+
+(unless (file-directory-p notmuch-dev-temporary-repository-path)
+  (error git clone failed.
+
+(defun notmuch-dev-checkout-master ()
+  (magit-checkout master))
+
+(defun notmuch-dev-delete-branch (name)
+  (magit-delete-branch name))
+
+(defun notmuch-dev-create-branch (name)
+  ;; Switches to the new branch automatically.
+  (magit-create-branch name master))
+
+(defun notmuch-dev-flatten-title (title)
+  (let* ((s (downcase title))
+(s (replace-regexp-in-string [ \t/]+ - s))
+(s (replace-regexp-in-string [\]\[\:]  s))
+(s (replace-regexp-in-string \\.$  s))
+)
+s))
+
+(defun notmuch-dev-title-to-branch (title)
+  (concat review/ (notmuch-dev-flatten-title title)))
+
+(defun notmuch-dev-title-to-mbox (title)
+  (concat notmuch-dev-temporary-directory /
+ (notmuch-dev-flatten-title title) .mbox))
+
+;;
+
+(defun notmuch-dev-show-review-patch ()
+  Call this from `notmuch-show-mode'.
+  (interactive)
+
+  (notmuch-dev-review-patch (notmuch-show-get-subject)
+   (mapconcat 'identity
+  
(notmuch-show-get-message-ids-for-open-messages)
+   OR )))
+
+(defun notmuch-dev-review-patch (title search-terms)
+  (let ((patch-name (notmuch-dev-title-to-branch title))
+   (mbox-path (notmuch-dev-title-to-mbox title)))
+
+(notmuch-dev-make-temporary-repository)
+
+;; Switch to the repository directory.
+(let ((default-directory notmuch-dev-temporary-repository-path))
+
+  (notmuch-dev-checkout-master)
+  ;; Delete the branch if it exists.
+  (condition-case nil
+ (notmuch-dev-delete-branch patch-name)
+   (error nil))
+  (notmuch-dev-create-branch patch-name)
+
+  ;; Have notmuch generate mailbox format output for the search
+  ;; terms...
+  (with-temp-file mbox-path
+   (erase-buffer)
+   (call-process notmuch-command nil t nil
+ show --format=mbox search-terms))
+
+  ;; ...and feed that to git-am.
+  (magit-run* (list magit-git-executable am mbox-path))
+
+  (magit-status notmuch-dev-temporary-repository-path
+
+;;
+
+(provide 'notmuch-dev)
-- 
1.7.7.3

___
notmuch 

[PATCH] emacs: Mark the quoted region during reply.

[David Edmondson]

Mark the quoted region of text during a reply, making it easy for the
user to delete it quickly.
---
 emacs/notmuch-mua.el |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 7114e48..32e2e30 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -108,7 +108,8 @@ list.
 (if (re-search-backward message-signature-separator nil t)
  (forward-line -1)
   (goto-char (point-max)))
-(insert body))
+(insert body)
+(push-mark))
   (set-buffer-modified-p nil)
 
   (message-goto-body))
-- 
1.7.7.3

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

Re: Exporting mime email

[Mark Walters]

Hello

On Fri, 06 Jan 2012 08:35:27 +, David Edmondson d...@dme.org wrote:
 On Fri, 06 Jan 2012 00:29:39 +, Mark Walters markwalters1...@gmail.com 
 wrote:
  What is the best way of exporting/saving as text a mime-encoded email
  from the emacs interface (e.g, if I want to save a mime-encoded email
  containing a patch)?
  
  For non-mime emails View-raw is fine, but with mime encoded emails such
  as (picked pretty much at random)
  id:1325240897-27525-1-git-send-email-...@dme.org
  I haven't found any non-hack method.
 
 That message is 8bit UTF-8 at my end. Saving it use '|' works just fine
 for me. What encoding do you see?

Does saving the message like this give you a file you can apply directly
with the patch command? When I save it (using | or from view-raw) I get
a message which looks like

(Delivery headers)
From: ...
To: ...
Subject: =?UTF-8?q?=5BPATCH=5D=20emacs=3A=20Improved=20printing=20support=2E?=
Date: ..
(some X and list headers)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Sender: notmuch-boun...@notmuchmail.org
Errors-To: notmuch-boun...@notmuchmail.org

QWRkIHZhcmlvdXMgZnVuY3Rpb25zIHRvIHByaW50IG5vdG11Y2ggbWVzc2FnZXMgYW5kIHRpZSB0
aGVtIHRvZ2V0aGVyCndpdGggYSBzaW1wbGUgZnJvbnRlbmQuIE5vIGtleWJpbmRpbmcgaXMgY3Vy
cmVudGx5IG1hZGUgdG8gZW5jb3VyYWdlCnBhcGVyIHNhdmluZy4KLS0tCgpSZXN1cnJlY3Rpbmcg
.. for 100 lines or so

The saved file is identical to the file  in my maildir. But feeding it
to patch in the form  patch -p1  exported_file does not work.

I have just discovered git am which solves this problem for patches but
I think it might be useful to be able to export the plain-text email
sometimes.

(If this is all some messed up utf-8 settings my end then many apologies
for the noise)

Many thanks 

Mark




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

Re: Exporting mime email

[David Edmondson]

On Fri, 06 Jan 2012 10:27:16 +, Mark Walters markwalters1...@gmail.com 
wrote:
 Does saving the message like this give you a file you can apply directly
 with the patch command? When I save it (using | or from view-raw) I get
 a message which looks like

Ahh. This particular message is a bad example for me to check, because I
have the version that I bcc'd rather than the one delivered by the
mailing list.

Presumably something is converting it from 8bit to base64 along the
path.

I scouted around for other messages that include © (which is what I
presume causes the encoding), but the ones I have are all still 8bit.

 I have just discovered git am which solves this problem for patches but
 I think it might be useful to be able to export the plain-text email
 sometimes.

Agreed.


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

Re: Exporting mime email

[Mark Walters]

Hi

 Presumably something is converting it from 8bit to base64 along the
 path.

If it makes a difference my setup is gmail-offlineimap-notmuch

 I scouted around for other messages that include © (which is what I
 presume causes the encoding), but the ones I have are all still 8bit.

A different example which shows the same problem (for me) is
id:m2fwg1uapw@gmail.com

Many thanks

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

Re: Exporting mime email

[David Edmondson]

On Fri, 06 Jan 2012 10:51:47 +, Mark Walters markwalters1...@gmail.com 
wrote:
  Presumably something is converting it from 8bit to base64 along the
  path.
 
 If it makes a difference my setup is gmail-offlineimap-notmuch

Mine is the same for the relevant messages.

  I scouted around for other messages that include © (which is what I
  presume causes the encoding), but the ones I have are all still 8bit.
 
 A different example which shows the same problem (for me) is
 id:m2fwg1uapw@gmail.com

This one is encoded as quoted-printable. I agree that the output of
 | cat /tmp/file
in the emacs UI produces the encoded file and that it is identical to
the file on disk.

Hence, I can reproduce the problem you reported :-)

(Maybe amusingly) the printing stuff that you originally mentioned
included some code to produce a 'text' version of a message for
printing. Maybe that could also be used to implement a simple
`notmuch-show-save-message' command?


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

Re: [PATCH] Perform mail polling asynchronously

[Antono Vasiljev]

On Tue, 2012-01-03 at 16:02 +, David Edmondson wrote:

 On Mon,  5 Sep 2011 07:14:36 +0300, Antono Vasiljev s...@antono.info wrote:
* reimplemented notmuch-poll(optional callback) so that it
  calls process asynchronously and run callback after process
  finished
* changed usage of notmuch-poll in notmuch-hello-poll-and-update
  and notmuch-search-poll-and-refresh-view
 
 I don't understand the real purpose of this patch.

 If the poll script runs asynchronously, won't the notmuch-search output
 refresh and jump into my face when I'm busy doing something else? And,
 if I'm not busy doing something else, why can't I just wait for the poll
 script to complete?

Sync io sucks.
Just drop it if you do not like. I don't use notmuch anymore so i dont
care.



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

Re: [PATCH] Perform mail polling asynchronously

[David Edmondson]

On Fri, 06 Jan 2012 14:09:57 +0300, Antono Vasiljev s...@antono.info wrote:
 On Tue, 2012-01-03 at 16:02 +, David Edmondson wrote:
 
  On Mon,  5 Sep 2011 07:14:36 +0300, Antono Vasiljev s...@antono.info 
  wrote:
 * reimplemented notmuch-poll(optional callback) so that it
   calls process asynchronously and run callback after process
   finished
 * changed usage of notmuch-poll in notmuch-hello-poll-and-update
   and notmuch-search-poll-and-refresh-view
  
  I don't understand the real purpose of this patch.
 
  If the poll script runs asynchronously, won't the notmuch-search output
  refresh and jump into my face when I'm busy doing something else? And,
  if I'm not busy doing something else, why can't I just wait for the poll
  script to complete?
 
 Sync io sucks.
 Just drop it if you do not like. I don't use notmuch anymore so i dont
 care.

Antono, thanks for replying. I'll mark the patch as 'obsolete'.


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

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

[David Bremner]

On Fri, 06 Jan 2012 10:11:42 +0200, Jani Nikula j...@nikula.org wrote:

 IMHO the first is cleanest and unaffected by changes in
 notmuch_show_params_t, though might be surprising if you're not (yet)
 used to C99 designated initializers.

Obviously not ;). It would nice to have a consensus about the use of C99
features in the notmuch code. Personally I think it's fine, but I know
we have had some back and forth about e.g. mid-block variable declarations.

 In any case, in the current implementation only .part and .cryptoctx are
 initialized, and the rest of the fields are random. This needs to be
 fixed one way or another.

Agreed.

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

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

[David Bremner]

On Wed,  4 Jan 2012 15:26:52 +0200, Tomi Ollila tomi.oll...@iki.fi wrote:
 ---
 This patch is submitted on release branch.
  NEWS |   16 
  1 files changed, 8 insertions(+), 8 deletions(-)

Hi Tomi;

It seems like applying this to release is just asking for trouble. It is
already quite an ordeal merging patches for NEWS. Is there some urgency
for this in terms of supporting automated posting of NEWS to the wiki?

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

Re: [PATCH 0/4] notmuch reply bugfix reply to sender only

[Jani Nikula]

Hi Mark -

On Thu, 05 Jan 2012 22:01:30 +, Mark Walters markwalters1...@gmail.com 
wrote:
  Bikeshedding topic #1: How about making replying to just the sender the 
  default
  in notmuch reply, and having --reply-all option (instead of 
  --no-reply-all)?
 
 In id:87pqn5cg4g@yoom.home.cworth.org cworth suggested using
 --reply-to=sender vs. --reply-to=all (keeping the latter the default).

That is a sound proposal too, leaving room for extension if such need
might arise.

 However, one more significant choice is what to do on reply-to-sender to
 an email from the user himself. My patch used the following logic: look
 at the reply-to, from , to, cc lines until you find a non-user address
 and use that line for the reply. My recollection is that this is roughly
 what mutt does.

That is a very good point, and one that my patch fails to address.

 (*) I have a version of that patch-set which applies to master if that
 would be useful to anyone, and I recently started writing tests in
 preparation for re-submitting.

Ah, it's old, no wonder I didn't know about it. Looking at the v2 of it
that I found gmane, it looks like the approach is roughly the same.

I think me passing the 'add' parameter makes things a bit more obvious
and explicit, while your use of g_mime_message_get_all_recipients
(reply) == NULL might be more robust (including handling reply to
user's own message). Switching to new style argument parsing is probably
something David will insist on, and that's a ready, independent patch in
my set. On emacs side I think my patch is just slightly cleaner, but no
big difference.

How about you post what you have now as a reply to this thread, and let
others be the judge? I really don't mind whether it's you or I who
finishes this as long as we get the feature, and preferrably combining
the best of what we both have. I'm also open to splitting this between
you and me; just let me know what you think.


BR,
Jani.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 0/4] notmuch reply bugfix reply to sender only

[Mark Walters]

 That is a very good point, and one that my patch fails to address.
 
  (*) I have a version of that patch-set which applies to master if that
  would be useful to anyone, and I recently started writing tests in
  preparation for re-submitting.
 
 Ah, it's old, no wonder I didn't know about it. Looking at the v2 of it
 that I found gmane, it looks like the approach is roughly the same.
 
 I think me passing the 'add' parameter makes things a bit more obvious
 and explicit, while your use of g_mime_message_get_all_recipients
 (reply) == NULL might be more robust (including handling reply to
 user's own message). Switching to new style argument parsing is probably
 something David will insist on, and that's a ready, independent patch in
 my set. On emacs side I think my patch is just slightly cleaner, but no
 big difference.

I have not had a chance to look at your code yet: I will try to do so
this afternoon.

 How about you post what you have now as a reply to this thread, and let
 others be the judge? I really don't mind whether it's you or I who
 finishes this as long as we get the feature, and preferrably combining
 the best of what we both have. I'm also open to splitting this between
 you and me; just let me know what you think.

I will post it as a reply to this message. I don't mind which version
goes in either (but it would  be nice if some version did!)

Best wishes

Mark

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

[PATCH 1/4] Add the option --reply-to to notmuch reply.

[Mark Walters]

Possible values for this option are sender which replies just to
sender and all (the default).

More precisely reply to sender follows these rules:
reply only to sender unless it was the user
reply only to all people on the to line unless they were all the user
reply to all people on the cc line

Implementation details

We continue parsing addresses beyond the ones we reply to because
we want to make sure the from address is correct. (At the very least it
is the same as it would be if we replied to all.)

We overload the message variable in add_recipients_for_address_list so
if it is NULL we parse the address (looking for the users address)
but do not add to the message recipients list

We add the variable reply_to_all to the function chain to keep track
of whether we should reply to everyone.
---
 notmuch-reply.c |   48 +---
 1 files changed, 37 insertions(+), 11 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index f8d5f64..9a77fe6 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -212,7 +212,8 @@ add_recipients_for_address_list (GMimeMessage *message,
if (ret == NULL)
ret = addr;
} else {
-   g_mime_message_add_recipient (message, type, name, addr);
+if (message)
+ g_mime_message_add_recipient (message, type, name, addr);
}
}
 }
@@ -292,7 +293,8 @@ reply_to_header_is_redundant (notmuch_message_t *message)
 static const char *
 add_recipients_from_message (GMimeMessage *reply,
 notmuch_config_t *config,
-notmuch_message_t *message)
+notmuch_message_t *message,
+int reply_to_all)
 {
 struct {
const char *header;
@@ -332,9 +334,20 @@ add_recipients_from_message (GMimeMessage *reply,
recipients = notmuch_message_get_header (message,
 reply_to_map[i].fallback);
 
-   addr = add_recipients_for_string (reply, config,
- reply_to_map[i].recipient_type,
- recipients);
+
+   /* We add the addresses if we are replying to all or we have not yet 
found
+* a non-user address. We have to keep parsing to make sure we do find 
the
+* correct from address for the user, but we pass a NULL message
+*/
+   if ((reply_to_all) || (g_mime_message_get_all_recipients (reply) == 
NULL))
+   addr = add_recipients_for_string (reply, config,
+ reply_to_map[i].recipient_type,
+ recipients);
+   else
+addr = add_recipients_for_string (NULL, config,
+  reply_to_map[i].recipient_type,
+  recipients);
+
if (from_addr == NULL)
from_addr = addr;
 }
@@ -480,7 +493,8 @@ static int
 notmuch_reply_format_default(void *ctx,
 notmuch_config_t *config,
 notmuch_query_t *query,
-notmuch_show_params_t *params)
+notmuch_show_params_t *params,
+int reply_to_all)
 {
 GMimeMessage *reply;
 notmuch_messages_t *messages;
@@ -509,7 +523,7 @@ notmuch_reply_format_default(void *ctx,
g_mime_message_set_subject (reply, subject);
}
 
-   from_addr = add_recipients_from_message (reply, config, message);
+   from_addr = add_recipients_from_message (reply, config, message, 
reply_to_all);
 
if (from_addr == NULL)
from_addr = guess_from_received_header (config, message);
@@ -558,7 +572,8 @@ static int
 notmuch_reply_format_headers_only(void *ctx,
  notmuch_config_t *config,
  notmuch_query_t *query,
- unused (notmuch_show_params_t *params))
+ unused (notmuch_show_params_t *params),
+ int reply_to_all)
 {
 GMimeMessage *reply;
 notmuch_messages_t *messages;
@@ -598,7 +613,7 @@ notmuch_reply_format_headers_only(void *ctx,
g_mime_object_set_header (GMIME_OBJECT (reply),
  References, references);
 
-   (void)add_recipients_from_message (reply, config, message);
+   (void)add_recipients_from_message (reply, config, message, 
reply_to_all);
 
reply_headers = g_mime_object_to_string (GMIME_OBJECT (reply));
printf (%s, reply_headers);
@@ -620,7 +635,8 @@ notmuch_reply_command (void *ctx, int argc, char *argv[])
 notmuch_query_t *query;
 char *opt, *query_string;
 int i, ret = 0;
-

[PATCH 3/4] Emacs changes for reply-to-sender

[Mark Walters]

Reply to sender is currently bound to R
---
 emacs/notmuch-mua.el  |8 +---
 emacs/notmuch-show.el |8 +++-
 emacs/notmuch.el  |2 +-
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 7114e48..7171210 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -71,12 +71,14 @@ list.
(push header message-hidden-headers)))
notmuch-mua-hidden-headers))
 
-(defun notmuch-mua-reply (query-string optional sender)
+(defun notmuch-mua-reply (query-string option-string optional sender)
   (let (headers
body
(args '(reply)))
 (if notmuch-show-process-crypto
(setq args (append args '(--decrypt
+(if option-string
+   (setq args (append args (list option-string
 (setq args (append args (list query-string)))
 ;; This make assumptions about the output of `notmuch reply', but
 ;; really only that the headers come first followed by a blank
@@ -217,13 +219,13 @@ the From: address first.
(notmuch-mua-forward-message))
 (notmuch-mua-forward-message)))
 
-(defun notmuch-mua-new-reply (query-string optional prompt-for-sender)
+(defun notmuch-mua-new-reply (query-string option-string optional 
prompt-for-sender)
   Invoke the notmuch reply window.
   (interactive P)
   (let ((sender
 (when prompt-for-sender
   (notmuch-mua-prompt-for-sender
-(notmuch-mua-reply query-string sender)))
+(notmuch-mua-reply query-string option-string sender)))
 
 (defun notmuch-mua-send-and-exit (optional arg)
   (interactive P)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 5502efd..40bea0c 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -933,6 +933,7 @@ thread id.  If a prefix is given, crypto processing is 
toggled.
(define-key map m 'notmuch-mua-new-mail)
(define-key map f 'notmuch-show-forward-message)
(define-key map r 'notmuch-show-reply)
+   (define-key map R 'notmuch-show-reply-sender)
(define-key map | 'notmuch-show-pipe-message)
(define-key map w 'notmuch-show-save-attachments)
(define-key map V 'notmuch-show-view-raw-message)
@@ -1239,7 +1240,12 @@ any effects from previous calls to
 (defun notmuch-show-reply (optional prompt-for-sender)
   Reply to the current message.
   (interactive P)
-  (notmuch-mua-new-reply (notmuch-show-get-message-id) prompt-for-sender))
+  (notmuch-mua-new-reply (notmuch-show-get-message-id) nil prompt-for-sender))
+
+(defun notmuch-show-reply-sender (optional prompt-for-sender)
+  Reply to the current message but only to sender.
+  (interactive P)
+  (notmuch-mua-new-reply (notmuch-show-get-message-id) --reply-to=sender 
prompt-for-sender))
 
 (defun notmuch-show-forward-message (optional prompt-for-sender)
   Forward the current message.
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index fde2377..022b867 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -444,7 +444,7 @@ Complete list of currently available key bindings:
   Begin composing a reply to the entire current thread in a new buffer.
   (interactive P)
   (let ((message-id (notmuch-search-find-thread-id)))
-(notmuch-mua-new-reply message-id prompt-for-sender)))
+(notmuch-mua-new-reply message-id nil prompt-for-sender)))
 
 (defun notmuch-call-notmuch-process (rest args)
   Synchronously invoke \notmuch\ with the given list of arguments.
-- 
1.7.2.3

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

[PATCH 4/4] add tests for reply-to-sender

[Mark Walters]

---
 test/notmuch-test|1 +
 test/reply-to-sender |  209 ++
 2 files changed, 210 insertions(+), 0 deletions(-)
 create mode 100755 test/reply-to-sender

diff --git a/test/notmuch-test b/test/notmuch-test
index e40ef86..6a99ae3 100755
--- a/test/notmuch-test
+++ b/test/notmuch-test
@@ -33,6 +33,7 @@ TESTS=
   thread-naming
   raw
   reply
+  reply-to-sender
   dump-restore
   uuencode
   thread-order
diff --git a/test/reply-to-sender b/test/reply-to-sender
new file mode 100755
index 000..c7d15bb
--- /dev/null
+++ b/test/reply-to-sender
@@ -0,0 +1,209 @@
+#!/usr/bin/env bash
+test_description=\notmuch reply --reply-to=sender\ in several variations
+. ./test-lib.sh
+
+test_begin_subtest Basic reply-to-sender
+add_message '[from]=Sender sen...@example.com' \
+ [to]=test_su...@notmuchmail.org \
+ [subject]=notmuch-reply-test \
+'[date]=Tue, 05 Jan 2010 15:43:56 -' \
+'[body]=basic reply-to-sender test'
+
+output=$(notmuch reply --reply-to=sender id:${gen_msg_id})
+test_expect_equal $output From: Notmuch Test Suite 
test_su...@notmuchmail.org
+Subject: Re: notmuch-reply-test
+To: Sender sen...@example.com
+In-Reply-To: ${gen_msg_id}
+References: ${gen_msg_id}
+
+On Tue, 05 Jan 2010 15:43:56 -, Sender sen...@example.com wrote:
+ basic reply-to-sender test
+
+test_begin_subtest From Us, Basic reply to message
+add_message '[from]=Notmuch Test Suite test_su...@notmuchmail.org' \
+'[to]=Recipient recipi...@example.com' \
+ [subject]=notmuch-reply-test \
+'[date]=Tue, 05 Jan 2010 15:43:56 -' \
+'[body]=basic reply-to-from-us test'
+
+output=$(notmuch reply --reply-to=sender id:${gen_msg_id})
+test_expect_equal $output From: Notmuch Test Suite 
test_su...@notmuchmail.org
+Subject: Re: notmuch-reply-test
+To: Recipient recipi...@example.com
+In-Reply-To: ${gen_msg_id}
+References: ${gen_msg_id}
+
+On Tue, 05 Jan 2010 15:43:56 -, Notmuch Test Suite 
test_su...@notmuchmail.org wrote:
+ basic reply-to-from-us test
+
+test_begin_subtest Multiple recipients
+add_message '[from]=Sender sen...@example.com' \
+'[to]=test_su...@notmuchmail.org, Someone Else 
some...@example.com' \
+ [subject]=notmuch-reply-test \
+'[date]=Tue, 05 Jan 2010 15:43:56 -' \
+'[body]=Multiple recipients'
+
+output=$(notmuch reply  --reply-to=sender  id:${gen_msg_id})
+test_expect_equal $output From: Notmuch Test Suite 
test_su...@notmuchmail.org
+Subject: Re: notmuch-reply-test
+To: Sender sen...@example.com
+In-Reply-To: ${gen_msg_id}
+References: ${gen_msg_id}
+
+On Tue, 05 Jan 2010 15:43:56 -, Sender sen...@example.com wrote:
+ Multiple recipients
+
+test_begin_subtest From Us, Multiple TO recipients
+add_message '[from]=Notmuch Test Suite test_su...@notmuchmail.org' \
+'[to]=Recipient recipi...@example.com, Someone Else 
some...@example.com' \
+ [subject]=notmuch-reply-test \
+'[date]=Tue, 05 Jan 2010 15:43:56 -' \
+'[body]=From Us, Multiple TO recipients'
+
+output=$(notmuch reply  --reply-to=sender  id:${gen_msg_id})
+test_expect_equal $output From: Notmuch Test Suite 
test_su...@notmuchmail.org
+Subject: Re: notmuch-reply-test
+To: Recipient recipi...@example.com, Someone Else some...@example.com
+In-Reply-To: ${gen_msg_id}
+References: ${gen_msg_id}
+
+On Tue, 05 Jan 2010 15:43:56 -, Notmuch Test Suite 
test_su...@notmuchmail.org wrote:
+ From Us, Multiple TO recipients
+
+test_begin_subtest Reply with CC
+add_message '[from]=Sender sen...@example.com' \
+ [to]=test_su...@notmuchmail.org \
+'[cc]=Other Parties c...@example.com' \
+ [subject]=notmuch-reply-test \
+'[date]=Tue, 05 Jan 2010 15:43:56 -' \
+'[body]=reply with CC'
+
+output=$(notmuch reply  --reply-to=sender id:${gen_msg_id})
+test_expect_equal $output From: Notmuch Test Suite 
test_su...@notmuchmail.org
+Subject: Re: notmuch-reply-test
+To: Sender sen...@example.com
+In-Reply-To: ${gen_msg_id}
+References: ${gen_msg_id}
+
+On Tue, 05 Jan 2010 15:43:56 -, Sender sen...@example.com wrote:
+ reply with CC
+
+test_begin_subtest From Us, Reply with CC
+add_message '[from]=Notmuch Test Suite test_su...@notmuchmail.org' \
+'[to]=Recipient recipi...@example.com' \
+'[cc]=Other Parties c...@example.com' \
+ [subject]=notmuch-reply-test \
+'[date]=Tue, 05 Jan 2010 15:43:56 -' \
+'[body]=reply with CC'
+
+output=$(notmuch reply  --reply-to=sender id:${gen_msg_id})
+test_expect_equal $output From: Notmuch Test Suite 
test_su...@notmuchmail.org
+Subject: Re: notmuch-reply-test
+To: Recipient recipi...@example.com
+In-Reply-To: ${gen_msg_id}
+References: ${gen_msg_id}
+
+On Tue, 05 Jan 2010 15:43:56 -, Notmuch Test Suite 
test_su...@notmuchmail.org wrote:
+ reply with CC
+

Re: [PATCH] Perform mail polling asynchronously

[Jesse Rosenthal]

On Tue, 03 Jan 2012 16:02:43 +, David Edmondson d...@dme.org wrote:
 On Mon,  5 Sep 2011 07:14:36 +0300, Antono Vasiljev s...@antono.info wrote:

 If the poll script runs asynchronously, won't the notmuch-search output
 refresh and jump into my face when I'm busy doing something else? And,
 if I'm not busy doing something else, why can't I just wait for the poll
 script to complete?

Well, he might have dropped it (and notmuch), but I've been wondering
about the possibilities of this for the emacs client. What I was
imagining was some sort of modeline notifier, like what ERC offers. It
could easily alert you without jumping into your face.

Just musing -- I haven't had time to actually think it all the way
through.

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

Re: [PATCH] Perform mail polling asynchronously

[David Edmondson]

On Fri, 06 Jan 2012 06:45:59 -0800, Jesse Rosenthal jrosent...@jhu.edu wrote:
 On Tue, 03 Jan 2012 16:02:43 +, David Edmondson d...@dme.org wrote:
  On Mon,  5 Sep 2011 07:14:36 +0300, Antono Vasiljev s...@antono.info 
  wrote:
 
  If the poll script runs asynchronously, won't the notmuch-search output
  refresh and jump into my face when I'm busy doing something else? And,
  if I'm not busy doing something else, why can't I just wait for the poll
  script to complete?
 
 Well, he might have dropped it (and notmuch), but I've been wondering
 about the possibilities of this for the emacs client. What I was
 imagining was some sort of modeline notifier, like what ERC offers. It
 could easily alert you without jumping into your face.

It sounds useful, but that patch is not it.


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

Re: [RFC][PATCH] emacs: Use text properties rather than overlays in various places.

[Jameson Graef Rollins]

On Wed, 28 Dec 2011 14:31:31 +, David Edmondson d...@dme.org wrote:
 Probably just for aficionados at the moment...

Actually, I think that all the rest of these comments should be included
in the log.  There's useful discussion here.

 Given that clashes between overlays and text properties are a problem
 and overlays are considered expensive, switching to text properties
 makes sense. For example, the coloured tags in the headerline are back
 with this patch.

I actually currently have colored tags in the headerline.  Did they go
somewhere at some point?

jamie.


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

Re: [PATCH 2/2] test: Add tests for advance/rewind.

[Jameson Graef Rollins]

On Thu, 29 Dec 2011 16:05:39 +, David Edmondson d...@dme.org wrote:
 What's the general feeling about this approach to producing tests for
 the emacs UI? (That is, code the test in a .el file and call the
 relevant function(s) from the test harness.)

I think it's a nice idea.  It seems much cleaner than writing ever more
complicated code in the command line.  There was another recent idea to
actually write the python tests in python, if I remember correctly.  It
all seems to make sense to me.  Bash is convenient, but there's no
reason we need to be monogamous, especially when there are ways, with
your technique, to call individual embedded tests from the command
line and still take advantage of the bells and whistles of full test
infrastructure.

 It makes it simpler to develop and maintain the test (because you can do
 more work with traditional emacs support for editing elisp), but might
 make interpreting failures more difficult (the test harness mostly just
 reports 'failed').

It is really nice to see diffs on failure, actually, to get a sense of
what exactly went wrong.  Is it possible to have some sort of standard
report to stdout that could provide more info?

jamie.


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

Re: [RFC][PATCH] emacs: Use text properties rather than overlays in various places.

[David Edmondson]

On Fri, 06 Jan 2012 08:58:31 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Wed, 28 Dec 2011 14:31:31 +, David Edmondson d...@dme.org wrote:
  Probably just for aficionados at the moment...
 
 Actually, I think that all the rest of these comments should be included
 in the log.  There's useful discussion here.

Okay.

The work-in-progress `notmuch-mode' patches that Austin posted to lazily
construct the invisible overlays suggests a way that could be integrated
with these changes to further improve performance, but I haven't had
time to look at it yet.

  Given that clashes between overlays and text properties are a problem
  and overlays are considered expensive, switching to text properties
  makes sense. For example, the coloured tags in the headerline are back
  with this patch.
 
 I actually currently have colored tags in the headerline.  Did they go
 somewhere at some point?

I haven't looked properly, but I think that emacs 24 stole them. They
certainly were not updating correctly during the addition/removal of
tags.


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

Re: [PATCH 2/2] test: Add tests for advance/rewind.

[David Edmondson]

On Fri, 06 Jan 2012 09:10:17 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
  It makes it simpler to develop and maintain the test (because you can do
  more work with traditional emacs support for editing elisp), but might
  make interpreting failures more difficult (the test harness mostly just
  reports 'failed').
 
 It is really nice to see diffs on failure, actually, to get a sense of
 what exactly went wrong.

Agreed.

 Is it possible to have some sort of standard report to stdout that
 could provide more info?

A little syntactic sugar will improve things I expect (have to avoid
re-implementing ert though). I'll have a play.


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

Re: [PATCH 1/2] add notmuch keybinding 'd'

[Antoine Beaupré]

On Tue, 03 Jan 2012 21:57:22 +0200, Jani Nikula j...@nikula.org wrote:
 I wouldn't use it either, and I don't use deleted tag in the first
 place. And even if I used it, I'd still like to keep the distinction
 between deleted after reading and deleted unread, which this patch
 loses by removing the unread tag.

I have been using this for months now.

But honestly, I don't care much anymore: the hard part is not the tag,
it's what you do with it after (hint: just remove the damn file).

Most patches I have submitted here haven't been accepted and I have to
painfully reroll my own packages every time there's a new release, which
has been a very frustrating experience. To see such a trivial patch
obsoleted tops it.

For the curious, those (other) patches are:

 * lib: add 'safe' setting for flags
 * lib: Add back the synchronization of 'T' flag with deleted tag
 * run notmuch-hello-mode-hook at the end of the hello mode setup

Most of those do not change the current behavior, and I have been
running them for more than 4 months.

I'd very much like to get help to get this in... 

A.


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

Re: [PATCH 1/2] add notmuch keybinding 'd'

[Jameson Graef Rollins]

On Fri, 06 Jan 2012 15:10:57 -0500, Antoine Beaupré anar...@koumbit.org wrote:
 Most patches I have submitted here haven't been accepted and I have to
 painfully reroll my own packages every time there's a new release, which
 has been a very frustrating experience. To see such a trivial patch
 obsoleted tops it.

Don't be too over dramatic, Antoine.  A lot of patches have sat fallow
for a long time, and a lot of us maintain our own stuff on top what's in
master.

There's also been discussion on this particular topic since long before
you showed up.  cworth pushed back on adding a delete key until we had a
more integrated solution.  I think the same thing is happening here.

I'm going to take a crack at an implementation of this functionality
this weekend that I think will satisfy most of out needs.

jamie.


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

Re: [PATCH 1/2] add notmuch keybinding 'd'

[David Bremner]

On Fri, 06 Jan 2012 15:10:57 -0500, Antoine Beaupré anar...@koumbit.org wrote:
 On Tue, 03 Jan 2012 21:57:22 +0200, Jani Nikula j...@nikula.org wrote:

  * lib: add 'safe' setting for flags
  * lib: Add back the synchronization of 'T' flag with deleted tag
  * run notmuch-hello-mode-hook at the end of the hello mode setup

 
 Most of those do not change the current behavior, and I have been
 running them for more than 4 months.
 
 I'd very much like to get help to get this in... 

Hi Antoine;

I understand your frustration; it's not very motivating to feel
ignored. Over the last few months we have been working to develop a
patch review process for notmuch [1], but as you can see from [2] there
is still a backlog of patches that have not been reviewed, the two lib
patches you mention among them. More reviewers are always welcome ;).

David

[1]: http://notmuchmail.org/nmbug/
[2]: http://nmbug.tethera.net/status/
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: Mark the quoted region during reply.

[Tomi Ollila]

On Fri,  6 Jan 2012 10:03:40 +, David Edmondson d...@dme.org wrote:
 Mark the quoted region of text during a reply, making it easy for the
 user to delete it quickly.
 ---

+1

Tomi

  emacs/notmuch-mua.el |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)
 
 diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
 index 7114e48..32e2e30 100644
 --- a/emacs/notmuch-mua.el
 +++ b/emacs/notmuch-mua.el
 @@ -108,7 +108,8 @@ list.
  (if (re-search-backward message-signature-separator nil t)
 (forward-line -1)
(goto-char (point-max)))
 -(insert body))
 +(insert body)
 +(push-mark))
(set-buffer-modified-p nil)
  
(message-goto-body))
 -- 
 1.7.7.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 1/2] add notmuch keybinding 'd'

[Tomi Ollila]

On Fri, 06 Jan 2012 15:10:57 -0500, Antoine Beaupré anar...@koumbit.org wrote:
 
 For the curious, those (other) patches are:
 
  * lib: add 'safe' setting for flags
  * lib: Add back the synchronization of 'T' flag with deleted tag
  * run notmuch-hello-mode-hook at the end of the hello mode setup

To add other replies, there are now notmuch-hello-mode-hook and
notmuch-hello-refresh-hook impmelented.

 Most of those do not change the current behavior, and I have been
 running them for more than 4 months.
 
 I'd very much like to get help to get this in... 
 
 A.

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

Re: [PATCH] run notmuch-hello-mode-hook at the end of the hello mode setup

[Jani Nikula]

Hi, looks like a similar patch has been applied as commit
db352df09e92171293eacf159342cd950ae596d0.

BR,
Jani.


On Mon,  8 Aug 2011 12:26:58 +0200, Antoine Beaupré anar...@koumbit.org wrote:
 i mostly use this to start offlineimap.el, but it could be used for
 other purposes. i have not added hooks to other modes, but those could
 be interesting as well. i am unsure as to how to make unit tests for
 this.
 ---
  emacs/notmuch-hello.el |6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)
 
 diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
 index 65fde75..6389ac8 100644
 --- a/emacs/notmuch-hello.el
 +++ b/emacs/notmuch-hello.el
 @@ -118,6 +118,11 @@ Typically \,\ in the US and UK and \.\ in Europe.
:group 'notmuch
:type 'string)
  
 +(defcustom notmuch-hello-mode-hook nil
 +  Hook run at the end of `notmuch-hello-mode'.
 +  :group 'notmuch
 +  :type 'hook)
 +
  (defvar notmuch-hello-url http://notmuchmail.org;
The `notmuch' web site.)
  
 @@ -336,6 +341,7 @@ Complete list of currently available key bindings:
   (setq major-mode 'notmuch-hello-mode
 mode-name notmuch-hello)
   ;;(setq buffer-read-only t)
 + (run-mode-hooks 'notmuch-hello-mode 'notmuch-hello-mode-hook)
  )
  
  (defun notmuch-hello-generate-tag-alist ()
 -- 
 1.7.2.5
 
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 0/4] notmuch reply bugfix reply to sender only

[Tomi Ollila]

On Thu, 5 Jan 2012 17:01:44 -0700, Adam Wolfe Gordon awg+notm...@xvx.ca wrote:
 On Thu, Jan 5, 2012 at 13:25, Jani Nikula j...@nikula.org wrote:
  Bikeshedding topic #1: How about making replying to just the sender the 
  default
  in notmuch reply, and having --reply-all option (instead of 
  --no-reply-all)?
 
  Bikeshedding topic #2: How about binding 'r' to reply to just the sender by
  default, and making 'R' reply-all (instead of vice versa)?
 
 I like both these suggestions.  This would bring the notmuch behavior
 in line with gmail, which is what I tend to expect.

I'd like that. I've already once sent a 'group reply' when I intended
to sent to only one.

+1 for changing 'r' reply sender and 'R' reply all in emacs MUA.

 Mark Walters brings up a good point, that there is a question of what
 to do when the user tries to reply to their own email.  When I do
 this, what I intend is to send another email to the last person I
 emailed in the thread, so I think the suggested heuristic of looking
 at other headers would work.  But, maybe others have a different
 expectation in this case?

Hmm, let's see there was 'Some User(TM)' sending email, and I reply all
to that. If I reply (to sender) to the email I just sent, The recipient
could be 'Some User(TM)' instead of me. Interesting possibility.

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

Re: [PATCH 2/2] lib: add 'safe' setting for flags

[Jani Nikula]

On Sat, 16 Jul 2011 23:56:13 -0400, Antoine Beaupré anar...@koumbit.org wrote:
 the 'safe' setting needs to be 'true' for flags to be manipulated by
 notmuch new/tag/restore.
 
 for now, only the (T)rash tag is configurable and set to false (by
 default) but this could be extended to allow the user to configure which
 flags are allowed to be synchronized.
 
 the reason why only T is configurable is because (a) it's the the only
 one that is actually dangerous and (b) I couldn't figure out how to
 properly configure multiple settings like this.
 ---
  lib/message.cc|   40 +---
  lib/notmuch.h |   20 
  notmuch-new.c |1 +
  notmuch-restore.c |1 +
  notmuch-tag.c |1 +
  5 files changed, 44 insertions(+), 19 deletions(-)
 
 diff --git a/lib/message.cc b/lib/message.cc
 index f633887..f812648 100644
 --- a/lib/message.cc
 +++ b/lib/message.cc
 @@ -50,16 +50,17 @@ struct maildir_flag_tag {
  char flag;
  const char *tag;
  bool inverse;
 +bool safe;
  };
  
  /* ASCII ordered table of Maildir flags and associated tags */
  static struct maildir_flag_tag flag2tag[] = {
 -{ 'D', draft,   false},
 -{ 'F', flagged, false},
 -{ 'P', passed,  false},
 -{ 'R', replied, false},
 -{ 'S', unread,  true },
 -{ 'T', deleted, false},
 +{ 'D', draft,   false, true},
 +{ 'F', flagged, false, true},
 +{ 'P', passed,  false, true},
 +{ 'R', replied, false, true},
 +{ 'S', unread,  true , true},
 +{ 'T', deleted, false, false},
  };
  
  /* We end up having to call the destructor explicitly because we had
 @@ -994,7 +995,6 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t 
 *message)
  char *combined_flags = talloc_strdup (message, );
  unsigned i;
  int seen_maildir_info = 0;
 -notmuch_bool_t reckless_trash;
  
  for (filenames = notmuch_message_get_filenames (message);
notmuch_filenames_valid (filenames);
 @@ -1022,15 +1022,8 @@ notmuch_message_maildir_flags_to_tags 
 (notmuch_message_t *message)
  if (status)
   return status;
  
 -// TODO: this should probably be moved up in the stack to avoid
 -// opening the config file on every message (!)
 -config = notmuch_config_open (ctx, NULL, NULL);
 -if (config == NULL)
 - return 1;
 -reckless_trash = notmuch_config_get_maildir_reckless_trash (config);
 -

Antoine -

You do *not* send a patch 1/2 that adds features and then 2/2 that takes
them away. I feel like I totally wasted my time reviewing the first.


Jani.



  for (i = 0; i  ARRAY_SIZE(flag2tag); i++) {
 - if (flag2tag[i].flag == 'T'  !reckless_trash) {
 + if (!flag2tag[i].safe) {
   continue;
   }
   if ((strchr (combined_flags, flag2tag[i].flag) != NULL)
 @@ -1119,6 +1112,9 @@ _get_maildir_flag_actions (notmuch_message_t *message,
   tag = notmuch_tags_get (tags);
  
   for (i = 0; i  ARRAY_SIZE (flag2tag); i++) {
 + if (!flag2tag[i].safe) {
 + continue;
 + }
   if (strcmp (tag, flag2tag[i].tag) == 0) {
   if (flag2tag[i].inverse)
   to_clear = talloc_asprintf_append (to_clear,
 @@ -1134,6 +1130,9 @@ _get_maildir_flag_actions (notmuch_message_t *message,
  
  /* Then, find the flags for all tags not present. */
  for (i = 0; i  ARRAY_SIZE (flag2tag); i++) {
 + if (!flag2tag[i].safe) {
 + continue;
 + }
   if (flag2tag[i].inverse) {
   if (strchr (to_clear, flag2tag[i].flag) == NULL)
   to_set = talloc_asprintf_append (to_set, %c, 
 flag2tag[i].flag);
 @@ -1256,6 +1255,17 @@ _new_maildir_filename (void *ctx,
  return filename_new;
  }
  
 +void
 +notmuch_message_set_flag_safety (char flag, notmuch_bool_t safe)
 +{
 +unsigned i;
 +for (i = 0; i  ARRAY_SIZE (flag2tag); i++) {
 +if (flag2tag[i].flag == flag) {
 +flag2tag[i].safe = safe;
 +}
 +}
 +}
 +
  notmuch_status_t
  notmuch_message_tags_to_maildir_flags (notmuch_message_t *message)
  {
 diff --git a/lib/notmuch.h b/lib/notmuch.h
 index f0c1b67..475e75a 100644
 --- a/lib/notmuch.h
 +++ b/lib/notmuch.h
 @@ -922,8 +922,7 @@ notmuch_message_remove_all_tags (notmuch_message_t 
 *message);
   *   'P' Adds the passed tag to the message
   *   'R' Adds the replied tag to the message
   *   'S' Removes the unread tag from the message
 - *   'T' Adds the deleted tag to the message and
 - *   state-reckless_trash is TRUE.
 + *   'T' Adds the deleted tag to the message
   *
   * For each flag that is not present, the opposite action (add/remove)
   * is performed for the corresponding tags.
 @@ -941,6 +940,9 @@ notmuch_message_remove_all_tags (notmuch_message_t 
 *message);
   * notmuch_database_add_message. See also
   * notmuch_message_tags_to_maildir_flags for synchronizing tag changes
   * back to maildir flags.
 + *
 + * Actions are performed 

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

[David Bremner]

On Thu,  5 Jan 2012 22:25:12 +0200, Jani Nikula j...@nikula.org wrote:
 notmuch_show_params_t params is only initialized partially in
 notmuch_reply_command(). The only field that is used uninitialized is
 params.decrypt. It is usually non-zero, making notmuch reply on encrypted
 messages work by coincidence.

Hi Jani;

I get one test failure with this patch on current master:

 FAIL   Reply within emacs
--- emacs.24.expected   2012-01-07 03:47:50.0 +
+++ emacs.24.output 2012-01-07 03:47:50.0 +
@@ -1,5 +1,5 @@
 From: Notmuch Test Suite test_su...@notmuchmail.org
-To: u...@example.com
+To: 
 Subject: Re: Testing message sent via SMTP
 In-Reply-To: XXX
 Fcc: /tmp/notmuch-dev-bremner/test/tmp.emacs/mail/sent

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

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

[Jani Nikula]

On Jan 7, 2012 5:52 AM, David Bremner da...@tethera.net wrote:

 On Thu,  5 Jan 2012 22:25:12 +0200, Jani Nikula j...@nikula.org wrote:
  notmuch_show_params_t params is only initialized partially in
  notmuch_reply_command(). The only field that is used uninitialized is
  params.decrypt. It is usually non-zero, making notmuch reply on
encrypted
  messages work by coincidence.

 Hi Jani;

 I get one test failure with this patch on current master:

Can't investigate right now, but did you try with just patch 1/4? (I really
should have separated the bug fix from the rest.)

J.


  FAIL   Reply within emacs
--- emacs.24.expected   2012-01-07 03:47:50.0 +
+++ emacs.24.output 2012-01-07 03:47:50.0 +
@@ -1,5 +1,5 @@
 From: Notmuch Test Suite test_su...@notmuchmail.org
-To: u...@example.com
+To:
 Subject: Re: Testing message sent via SMTP
 In-Reply-To: XXX
 Fcc: /tmp/notmuch-dev-bremner/test/tmp.emacs/mail/sent

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