notmuch emacs + msmtp sending issue fixed! :-)
aren.tyr at gmail.com
Tue Oct 29 09:53:03 PDT 2019
First of all, thanks to both of you (Tomi & Tomas) for your help.
I have finally solved the issue by my own self-investigation prompted by
a suggestion on reddit that wasn't the correct cause, but did send me on
what proved to be a successful path to a solution.
The poster had suggested I needed to disable the msmtp logging to a
logfile. This seemed like it wouldn't solve the issue as sending from
the command line worked fine for me with a 0 exit status. Still, I was
willing to give it a try.
I tried it, and as expected, it made no difference...
However, running it from the command line did highlight that I was always
getting some informational output to the console from gpg. I wondered whether
suppressing this might make a difference; perhaps it was interfering
with the return value to notmuch/emacs. What was interesting was that gpg was
spitting output to stderr, even though the output was *not* error, as
such; it was just informational output saying successful decryption,
etc. Even stranger, it was doing this despite having the -q (i.e. quiet)
flag. Adding the --no-verbose flag still wouldn't shut it up. OK, so how
about simply chucking this output away? After all, it wasn't actually
saying anything relevant or useful.So, in my msmtprc file, I changed the
passwordeval line to the following:
passwordeval gpg2 --no-tty -q -d ~/.mail/passwords/gmail-main.gpg 2> /dev/null
And tried to send an e-mail from notmuch....
In fact, for the first time, it actually brought up a prompt asking me
whether I wanted to (c)reate the necessary folder, which made sense. I
went ahead and created it. So it turns out:
a) My emacs config was fine
b) Notmuch was fine
c) gpg was chucking a load of informational output that notmuch/emacs
was interpreting as a non-zero exit code
d) worse, this output was causing the prompt to disappear to create the
I did further trials and tests and confirmed that the logfile option in
msmptp is fine. So the solution was simply to add
on the end of the passwordeval line to keep gpg quiet.
This line needs to be there, even with the necessary directory structure
in place (the 'cur', 'new', and 'tmp' folders under 'sent'), because it
still thinks the message hasn't been sent if isn't there. It is good to
have it there anyway, since I don't want the output of gpg anyway. It
should be pretty obvious if I mess-up entering the password.
> What are the values of send-mail-function and message-send-mail-function...
> If something like `message-smtpmail-send-it` then you could tru
> (setq smtpmail-debug-info t smtpmail-debug-verb t)
> and see what appeears in some new log buffers...)
> I /think/ that's all I have about the sending of mails and it works
> fine. (plus the msmtp configs of course).
> Best regards
Thanks once more.
> I used to have similar problem, and already wrote some elisp code to "fix"
> that (i.e. find suitable "parent" buffer and then switch there). Then I
> realized (i think someone(tm) commented on my suggestion) that there were
> problem in my emacs configuration -- and after I fixed that the buffer
> switching when closing search buffer worked basically as expected...
> i.e. when closing message buffer (and I have not one any other buffer
> manipulation) I ended back to search buffer, and from there back to hello
> If you have notmuch source code around you could try to run
> `devel/try-emacs-mua` and see whether you get different behavior when
> `-q` or `-Q` were used when running emags...
Yes, I still have this slight buffer order nuisance. I'll look into it
further and resolve it. I've got a fair bit going on in my spacemacs
setup, with a fair few layers and configuration options etc.
PS. This e-mail has been sent with my now fully working notmuch ;-)
More information about the notmuch