On Tue, 17 Jan 2012 09:19:51 +0000, David Edmondson <dme@dme.org> wrote:
> On Mon, 16 Jan 2012 23:48:30 -0500, Antoine Beaupré <anarcat@anarcat.ath.cx> wrote:
> > Jumping in here, I have modified the previously posted code here to
> > provide me with a more complete solution.
> 
> This looks good. I'll switch over to using it.

Awesome!

> > Code is attached. Obviously, those function names would change if they
> > would be to integrate into notmuch. ;)
> 
> I wondered about pushing to have notmuch do this by default. In general
> I like the idea, but it suffers if a recipient occasionally uses a mail
> client that does not support decryption (phone, PDA, webmail, ...).

Well, it your call: you can disable encryption on the fly by setting the
message to just signing...

I have also found out (to great pains) that it is kind of difficult to
*completely* disable signing or encrypting, as the send-hook will
happily add back the #secure line even if you remove it.

A workaround is to set "mode=none" in the #secure line manually. Maybe
C-c RET C-n could do that instead of just removing the line?

On Tue, 17 Jan 2012 15:39:52 +0000, David Edmondson <dme@dme.org> wrote:
> >        (if (and force (re-search-forward "<#secure [> >]*>\n" nil t))
> > 	   (replace-match "" nil nil))
> >        ;; If we can encrypt, do so, else just sign.
> >        (if (or force (not (re-search-forward "<#secure [> >]*>\n" nil t)))
> 
> Is this second test for `force' necessary? If `force' is set then you'll
> remove the <#secure..> just above, so it will not be found here.

Yes, it is. If force is true, the search-forward will not be ran at
all. The idea here is that if we do not force (ie. if we're running in
the hook), we do not want to override the existing #secure tags, to
respect the users' choices.

Cheers,

A.

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