I've tagged 0.24_rc0 (and uploaded it to Debian experimental). I hope to
release 0.24 in about a week. I've started NEWS, but there is a fair
amount I haven't covered. Please send patches for NEWS describing any
of your contributions that are user visible and reaching some subjective
threshold
When pkg-config does not find configure, a compat version of the
zlib.pc is created. In creation of that configure attempted to
read values of $zlib_cflags and $zlib_ldflags. In the usual case
those were undefined, and with `set -a` now in the beginning of
configure, configure broke.
Even if
Andreas Amann writes:
> Hi,
>
> I recently received some spam mails, which have a utf-16 byte order mark
> (BOM) U+FEFF as the first character in one of their "Received:"
> lines. When I run "notmuch new" I get the following:
>
> Note: Ignoring non-mail file:
David Edmondson writes:
> [ Trimmed to/cc list. ]
>
> On Sun, Jan 22 2012, Pieter Praet wrote:
>> * emacs/notmuch-show.el (notmuch-show-found-target-p): new predicate function
>> that uses notmuch(1) 'count' to see if a query turns up any results.
>>
>> * emacs/notmuch-show.el
Pieter Praet writes:
>
> Anti-RSI FTW!
>
> However... If no message with that id: exists, `notmuch-show'
> will drop us to a blank screen.
>
> See id:"87lisjzrsc@kepler.schwinge.homeip.net" for some mock
> 'id:' links which demonstrate this nicely.
This old bug seems
On Tue, 28 Feb 2017, David Bremner wrote:
> Sebastian Schwarz writes:
>> Even with all keys already present signature verification takes
>> some time as well. It would be nice if this was done
>> asynchronously as well. This would greatly improve the
Allan Streib writes:
> Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.1
>
> Replying to a message in a deeply nested thread can trigger a complaint:
>
> sendmail: command failed: 550 5.7.1 Delivery not authorized, message
> refused: Message is not RFC 2822 compliant
>
Lucas writes:
> Dear list members,
>
> I think I found a bug or at least undocumented behaviour in the notmuch
> library. I would like to report this here. Originally I found the bug
> in the python library but I attached a c program that shows the same
> behaviour. I am
This is primarily to be able to handle "text/plain; format=flowed",
but I don't see much point in making this specific to
format=flowed. Just include all content type parameters in the
formatted output, like this:
"content-type" : "text/plain",
"content-type-params" : [