[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.

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

[Jani Nikula]

On Jan 7, 2012 5:52 AM, "David Bremner"  wrote:
>
> 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:

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 
>-To: u...@example.com
>+To:
> Subject: Re: Testing message sent via SMTP
> In-Reply-To: 
> Fcc: /tmp/notmuch-dev-bremner/test/tmp.emacs/mail/sent
>
> d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[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

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  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: u...@example.com
+To: 
 Subject: Re: Testing message sent via SMTP
 In-Reply-To: 
 Fcc: /tmp/notmuch-dev-bremner/test/tmp.emacs/mail/sent

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

[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>

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

[David Edmondson]

On Fri, 06 Jan 2012 09:10:17 -0800, Jameson Graef Rollins  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.
-- 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/bb754ad0/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>

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

[Tomi Ollila]

On Wed,  4 Jan 2012 14:01:18 +, David Edmondson  wrote:
> ---
> 
> I've been using this for a few days and decided to share it to get
> feedback. Reviewing patches can be tedious, so I tried to make things
> a little simpler.
> 
> To use this, load the file and then from `notmuch-show-mode' invoke
> `notmuch-dev-show-review-patch'. It assumes that any open messages
> contain patches and attempts to build a repository with the patches
> applied.
> 
> 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.
> 
> If you have a slow network connection then a local copy of the main
> repository can be specified by changing
> `notmuch-dev-master-repository'.
> 
> Comments?

I think this is great. I've worked on something related but the emacs MUA
"integration" makes patching simpler (My thing worked on shell and would
require a 'recipe' file to describe HEAD commit and patch message id:s).

What I've done differently is that I already have cloned notmuch repository
somewhere which I attempt to keep up-to-date. For repository which I'm
going to patch I first do:

git clone --local --shared --no-checkout /path/to/notmuch/repo notmuch-dev-$USER
git --git-dir notmuch-dev-$USER/.git' config --unset remote.origin.url
cd notmuch-dev-$USER
git checkout -b patched $commit

I.e.

1) I created a local repository clone, sharing objects without initial checkout.
2) removed "remote" origin so accidental pushes are not possible
3) checkout out tree from some commit (possible not remote HEAD) 

And this is done every time before new patchset is applied -- always on top
of clean working directory.

What do you think of this approach related to your way cloning the repo and
then deleting/creating the branch. Just that developer may mess with the
repository contents and then there is tedious working tree cleanup to be
done (especially those who are not so fluent using git).


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é  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

Re: [PATCH 1/2] lib: Add back the synchronization of 'T' flag with deleted tag.

[Jani Nikula]

On Sat, 16 Jul 2011 23:56:12 -0400, Antoine Beaupré  wrote:
> This adds a special configuration, off by default, that allows notmuch
> to synchronize the T flag again. The configuration is named
> maildir_reckless_trash and quite clearly indicates that it could be
> dangerous to use in the context described in commit 2c26204, which I
> could actually reproduce.

Thanks for the commit reference.

Please find some comments below.

> In contexts where notmuch is the only mail client used, this is actually
> safe to use. Besides, (T)rashed messages are not necessarily immediately
> expunged from the Maildir by the client or the IMAP server.
> 
> Signed-off-by: Antoine Beaupré 
> ---
>  lib/message.cc   |   14 +-
>  lib/notmuch.h|4 
>  notmuch-client.h |7 +++
>  notmuch-config.c |   50 +++---
>  4 files changed, 71 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/message.cc b/lib/message.cc
> index d993cde..f633887 100644
> --- a/lib/message.cc
> +++ b/lib/message.cc
> @@ -58,7 +58,8 @@ static struct maildir_flag_tag flag2tag[] = {
>  { 'F', "flagged", false},
>  { 'P', "passed",  false},
>  { 'R', "replied", false},
> -{ 'S', "unread",  true }
> +{ 'S', "unread",  true },
> +{ 'T', "deleted", false},
>  };
>  
>  /* We end up having to call the destructor explicitly because we had
> @@ -993,6 +994,7 @@ 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);
> @@ -1020,7 +1022,17 @@ 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);

The config file is for notmuch the command line tool, *not* for the
lib. You can't call the cli from from the lib. The config (or command
line argument) should be passed as argument, but that would require
changing the lib interface.

> +if (config == NULL)
> + return 1;
> +reckless_trash = notmuch_config_get_maildir_reckless_trash (config);
> +
>  for (i = 0; i < ARRAY_SIZE(flag2tag); i++) {
> + if (flag2tag[i].flag == 'T' && !reckless_trash) {
> + continue;
> + }
>   if ((strchr (combined_flags, flag2tag[i].flag) != NULL)
>   ^ 
>   flag2tag[i].inverse)
> diff --git a/lib/notmuch.h b/lib/notmuch.h
> index 974be8d..f0c1b67 100644
> --- a/lib/notmuch.h
> +++ b/lib/notmuch.h
> @@ -922,6 +922,8 @@ 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.
>   *
>   * For each flag that is not present, the opposite action (add/remove)
>   * is performed for the corresponding tags.
> @@ -962,6 +964,8 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t 
> *message);
>   *   'P' iff the message has the "passed" tag
>   *   'R' iff the message has the "replied" tag
>   *   'S' iff the message does not have the "unread" tag
> + *   'T' iff the message has the "trashed" tag and
> + *   state->reckless_trash is TRUE.

"trashed" tag?

The comment (and the commit message) is incorrect. You only check for
reckless_trash in maildir_flags_to_tags, not tags_to_maildir_flags.
With this patch, one-way syncing from tags to flags would be done
unconditionally. And if I understand the problem correctly, you're
fixing the less critical one of the two!

I am wondering (but I'm too tired to check) if the original problem
could be avoided by simply refusing to sync "deleted" tag to 'T' flag if
there are more than one file for that message.

This is a dangerous feature, which is why it was originally
disabled. Accidentally deleting mail is not something people take
lightly. They'll be amused by "reckless trash" - until it recklessly
deletes an important mail.

However, something like this might be a useful feature to have for
people who want to delete mail. It would need good tests to accompany
it, though.


BR,
Jani.


>   *
>   * Any existing flags unmentioned in the list above will be preserved
>   * in the renaming.
> diff --git a/notmuch-client.h b/notmuch-client.h
> index 63be337..62d1e0e 100644
> --- a/notmuch-client.h
> +++ b/notmuch-client.h
> @@ -235,6 +235,13 @@ notmuch_config_set_maildir_synchronize_flags 
> (notmuch_config_t *config,
> notmuch_bool_t synchronize_flags);
>  
>  notmuch_bool_t
> +notmuch_con

[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

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  wrote:
> On Thu, Jan 5, 2012 at 13:25, Jani Nikula  wrote:
> > Bikeshedding topic #1: How about making replying to just the sender the 
> > default
> > in "notmuch reply", and having --reply-all option (instead of 
> > --no-reply-all)?
> >
> > Bikeshedding topic #2: How about binding 'r' to reply to just the sender by
> > default, and making 'R' reply-all (instead of vice versa)?
> 
> I like both these suggestions.  This would bring the notmuch behavior
> in line with gmail, which is what I tend to expect.

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

[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(&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.

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é  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 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
___
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 "' \
+ [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 &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

[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;

Re: [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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[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

Re: [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 
>  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
___
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  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'

[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/
___
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é  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

[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>

Re: [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.


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

[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(&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'.
-- 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

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

[David Edmondson]

On Fri, 06 Jan 2012 09:10:17 -0800, Jameson Graef Rollins 
 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] 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
___
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 
 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.


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.

[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.


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

[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>

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  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

[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>

Re: [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


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

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

Re: [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.


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

Re: [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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[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

Re: [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
___
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 "' \
+ [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 

+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_su...@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_su...@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 &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 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

___
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 

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

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  
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] 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
___
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  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] 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(&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] 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(&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: 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@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: 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: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.


pgp2EwbEtJliK.pgp
Description: PGP signature
___
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  wrote:
> On Fri, 06 Jan 2012 00:29:39 +, Mark Walters  
> wrote:
> > What is the best way of exporting/saving as text a mime-encoded email
> > from the emacs interface (e.g, if I want to save a mime-encoded email
> > containing a patch)?
> > 
> > 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

[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

[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

__

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

Re: [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.


pgpGncUG22Sfu.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  
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

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] 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...


pgpHN26I3fzGh.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"

[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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch