On Fri, Jan 01 2016, J Farkas
> From: Janos Farkas
> Subject: [PATCH] cli/insert: do not lose the SMTP envelope
> Make sure we store the envelope sender/recipient if provided by
> qmail-command(8) in $RPLINE and
On 2016-01-02 at 13:28:02, Tomi Ollila wrote:
> On Fri, Jan 01 2016, J Farkas
> > Make sure we store the envelope sender/recipient if provided by
> > qmail-command(8) in $RPLINE and $DTLINE.
> > ---
> Probably good feature, but like
This should be more readable.
emacs/notmuch-mua.el | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index d4950cb..2d6825d 100644
notmuch-mua-mail ignored the switch-function argument and always used
the function returned by notmuch-mua-get-switch-function instead. In
order to support standard emacs interfaces (compose-mail in this
case), this commit changes notmuch-mua-mail to use the switch-function
argument if it is
the first patch fixes the problem reported in
id:firstname.lastname@example.org. Patch 2/3 is just refactoring.
Patch 3/3 is reaction to id:email@example.com; I'm not
sure whether it addresses exactly what David had in mind, but IMHO it
is an improvement.
Commit 570c0aeb40bd0c3af8174624a55e968f62c44f09 reworked
notmuch-mua-mail function in a way that worked only under Emacs 24.
The reason was that message-setup-1 took one argument less in Emacs
We fix this by only supplying the return-action argument when it is
actually set by the caller.
On Fri, Jan 01 2016, David Bremner wrote:
> David Bremner writes:
>> Michal Sojka writes:
>>> This commit fixes these problems by replacing a call to message-mail
>>> with notmuch-specific code that is (hopefully) equivalent to
On Sat, Jan 02 2016, Michal Sojka wrote:
> the first patch fixes the problem reported in
> id:firstname.lastname@example.org. Patch 2/3 is just refactoring.
> Patch 3/3 is reaction to id:email@example.com; I'm not
> sure whether it addresses exactly what
I'm using notmuch-tree and I encountered a slightly annoying bug. When
browsing through a notmuch-tree buffer, if I open up a message whose
tags needs to be changed (eg. the message needs to be marked read), then
on the /next/ message, the bottom part of the pane does not get killed
On Wed, Dec 30 2015, fauno wrote:
> Michal Sojka writes:
>> can you share more details about how do you use jl-encrypt and which
>> functions do not work? Recently, I posted a few patches that fix some
>> problems related to the replacing message-mode with
Mail list logo