notmuch-mua-send + msmtp IS sending perfectly... but Emacs says it failed! Why?!

2019-10-25 Thread Aren Tyr
Hello all

I have setup mbsync to receive my e-mail, msmtp to send my mail, and use
notmuch + emacs to read/compose my mail. I have the msmtp-mta package also
installed, so that msmtp acts as a sendmail replacement. I have a bizarre
problem, however, which despite my searching I cannot find an answer to.

Every time I send a message (via notmuch-mua-send) from within Emacs, the
message apparently 'fails', and I get this error message:


Mark set [5 times]
Mark set [2 times]
Sending via mail...
message-send-mail-with-sendmail: Sending...failed to gpg: Signature made
Wed 09 Oct 2019 12:50:15 BST; gpg:using RSA key
C58AF6323354659D571F1DCA4AF54DEEDEA8938D; gpg:issuer ""; gpg: Good signature from "Aren Tyr (Key for encrypting mail
password files) " [ultimate];

I say 'fails', because in fact it DOES SEND, and it sends perfectly! I've
tested it with lots of e-mails, tested it with attachments, everything is
sending and working as it should be.

It is Emacs that is thinking it has failed, for whatever reason.

I've tried twiddling with every variable I can think of in Emacs to no
avail. Here are my relevant emacs settings:

(setq mail-specify-envelope-from 't)
(setq message-sendmail-envelope-from 'header)
(setq mail-envelope-from 'header)

My notmuch-config database path is set to:


I've set the emacs 'message-directory' variable to the same path, i.e.
~/.mail/. I've also tried manually creating 'sent' folders in the mail
store, just in case this was an issue, to no avail. (When I compose mail,
header has Fcc: sent ). notmuch-maildir-use-notmuch-insert is set to true.
notmuch-fcc-dirs is set to "sent". So everything should be set...

As a result, the buffer does not get closed/saved into the relevant sent
file, and it stays open as an "unsent" buffer, even though the message has
been sent fine. It is very irritating. To be clear, it is sending properly,
so it is correctly decrypting the password via gpg, so I don't know why it
is complaining and thinks there is a problem, when there isn't. Simply
sending an e-mail on the command line via mstmp also works perfectly
without any error, further verifying there is no configuration issue on the
actual mail transport side of things.

Any ideas? Why does emacs/notmuch think there is a problem sending, when
there isn't? What setting do I need to put into emacs to get it to shut-up
and accept that the mail has actually been sent, because it has in fact
been? :-D

In all other respects the mail setup is working perfectly, and I can
browse/search/read/view my e-mail just fine. It's a terrific program, thank

Well almost. One other slight nuisance. Whenever I close a message search
buffer, or a message reading buffer, instead of returning me to the
*notmuch hello* main buffer, it ALWAYS sends me to another buffer, usually
*scratch*. Never *notmuch hello*. It doesn't seem to matter what 'order'
the buffer is. I was expecting that after having started notmuch (M-x
notmuch), which brings up notmuch-hello, then immediately going into my
inbox (which opens a new buffer), opening an email (another new buffer),
closing it by pressing 'q', that I'd be returned back to my search list
since that is the immediately prior buffer. But no. It doesn't even return
me to notmuch-hello, which is the next one down. Instead it returns me to
another buffer, or *scratch*, or whatever. This is werid. It is like it is
ignoring the buffer list order. It means I have to manually switch buffers
back to the search list (or notmuch-hello). Emacs/notmuch seems to be
ignoring the buffer stack order, which is presumably not the intended
default operation. I don't understand enough about Emacs to know which
setting to tweak this. This is a minor distraction though, compared to the
sending issue I have described above.


notmuch mailing list

Re: Python3 cffi bindings

2019-10-25 Thread Floris Bruynooghe
On Tue 22 Oct 2019 at 13:32 -0300, David Bremner wrote:

> David Bremner  writes:
>> The LD_LIBRARY_PATH is already set by the test harness, as is PATH (to
>> find notmuch). It looks like your function notmuch is not respecting
>> PATH (see attached log). if I hack something like
>> diff --git a/bindings/python-cffi/tests/ 
>> b/bindings/python-cffi/tests/
>> index 1b7bbc35..ac17397c 100644
>> --- a/bindings/python-cffi/tests/
>> +++ b/bindings/python-cffi/tests/
>> @@ -31,7 +31,7 @@ def notmuch(maildir):
>>  accidentally do this in the unittests.
>>  """
>>  cfg_fname = maildir.path / 'notmuch-config'
>> -cmd = ['notmuch'] + list(args)
>> +cmd = ['../../notmuch'] + list(args)
>>  print('Invoking: {}'.format(' '.join(cmd)))
>>  proc =,
> I think I figured it out. Your 'run' function completely overrides the
> environment. But just adding PATH back seems to do the trick. I'm not
> sure if this is the most idomatic change, but it works:
> diff --git a/bindings/python-cffi/tests/ 
> b/bindings/python-cffi/tests/
> index 1b7bbc35..6a81aa18 100644
> --- a/bindings/python-cffi/tests/
> +++ b/bindings/python-cffi/tests/
> @@ -33,9 +33,11 @@ def notmuch(maildir):
>  cfg_fname = maildir.path / 'notmuch-config'
>  cmd = ['notmuch'] + list(args)
>  print('Invoking: {}'.format(' '.join(cmd)))
>proc =,
> -  env={'NOTMUCH_CONFIG': str(cfg_fname)})
> +  
> env={'PATH':os.environ["PATH"],'NOTMUCH_CONFIG': str(cfg_fname)})
>  proc.check_returncode()
>  return run

This seems reasonable, perhaps even a "env = os.environ.copy();
env['NOTMUCH_CONFIG'] = src(cfg_fname)" is better here so that
LD_LIBRARY_PATH and anything else is kept around.
notmuch mailing list

Re: [PATCH] Map missing content-type to "" instead of nil

2019-10-25 Thread David Edmondson
On Thursday, 2019-10-24 at 16:08:00 -07, wrote: 

From: Keith Packard  

When a message part has no content type, a 'nil' value results 
in many failures when passed to functions like 'downcase'. 
Instead of crashing, map a nil value to the empty string, "", so 
that the show operation doesn't crash. 

Signed-off-by: Keith Packard  --- 
 emacs/notmuch-show.el | 16 ++-- 1 file changed, 10 
 insertions(+), 6 deletions(-) 

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 
e13ca3d7..7e3d0501 100644 --- a/emacs/notmuch-show.el +++ 
b/emacs/notmuch-show.el @@ -556,6 +556,10 @@ message at DEPTH in 
the current thread." 
   "Alist from raw content ID to (MSG PART).") 
 (make-variable-buffer-local 'notmuch-show--cids)  
+(defun notmuch-show--plist-get(l m) 

We would generally have a space after “get”.

+  (let ((e (plist-get l m))) +(if e e ""))) 

Isn't this:

  (or (plist-get l m) "")

 (defun notmuch-show--register-cids (msg part)
   "Register content-IDs in PART and all of PART's sub-parts."
   (let ((content-id (plist-get part :content-id)))
@@ -570,7 +574,7 @@ message at DEPTH in the current thread."
   (push (list content-id msg part) notmuch-show--cids)))
   ;; Recurse on sub-parts
   (let ((ctype (notmuch-split-content-type
-   (downcase (plist-get part :content-type)
+   (downcase (notmuch-show--plist-get part :content-type)
 (cond ((equal (first ctype) "multipart")
   (mapc (apply-partially #'notmuch-show--register-cids msg)
 (plist-get part :content)))
@@ -594,7 +598,7 @@ will return nil if the CID is unknown or cannot be 
 ;; reference the same cid: part many times (hundreds!).
 (content (notmuch-get-bodypart-binary
   msg part notmuch-show-process-crypto 'cache))
-(content-type (plist-get part :content-type)))
+(content-type (notmuch-show--plist-get part :content-type)))
(list content content-type)
 (defun notmuch-show-setup-w3m ()

@@ -620,7 +624,7 @@ will return nil if the CID is unknown or cannot be 
 ;; MIME part renderers
 (defun notmuch-show-multipart/*-to-list (part)

-  (mapcar (lambda (inner-part) (plist-get inner-part :content-type))
+  (mapcar (lambda (inner-part) (notmuch-show--plist-get inner-part 
  (plist-get part :content)))
 (defun notmuch-show-insert-part-multipart/alternative (msg part content-type nth depth button)

@@ -631,7 +635,7 @@ will return nil if the CID is unknown or cannot be 
 ;; but it's not clear that this is the wrong thing to do - which
 ;; should be chosen if there are more than one that match?
 (mapc (lambda (inner-part)
-   (let* ((inner-type (plist-get inner-part :content-type))
+   (let* ((inner-type (notmuch-show--plist-get inner-part 
  (hide (not (or notmuch-show-all-multipart/alternative-parts
   (string= chosen-type inner-type)
  (notmuch-show-insert-bodypart msg inner-part depth hide)))
@@ -948,7 +952,7 @@ will return nil if the CID is unknown or cannot be 
 (defun notmuch-show-mime-type (part)

   "Return the correct mime-type to use for PART."
-  (let ((content-type (downcase (plist-get part :content-type
+  (let ((content-type (downcase (notmuch-show--plist-get part :content-type
 (or (and (string= content-type "application/octet-stream")
 (notmuch-show-get-mime-type-of-application/octet-stream part))
(and (string= content-type "inline patch")
@@ -989,7 +993,7 @@ HIDE determines whether to show or hide the part and the 
 as follows: If HIDE is nil, show the part and the button. If HIDE
 is t, hide the part initially and show the button."
-  (let* ((content-type (downcase (plist-get part :content-type)))

+  (let* ((content-type (downcase (notmuch-show--plist-get part :content-type)))
 (mime-type (notmuch-show-mime-type part))
 (nth (plist-get part :id))
 (long (and (notmuch-match-content-type mime-type "text/*")

notmuch mailing list

Music has magic, it's good clear syncopation.
notmuch mailing list