Istvan Marko writes:
> Xapian 1.3 has introduced the DB_RETRY_LOCK flag (Xapian bug
> 275). Detect it in configure and use it if available. With this flag
> commands that need the write lock will wait for their turn instead of
> aborting when it's not immediately available.
Variable CXXLAGS expands to nothing, CXXFLAGS something unusable
here; CXXFLAGS_for_sh expands to what we expect here.
---
I was palying with a patch set that enables 'set -eu' in usable way
when I noticed this...
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Tue, 03 May 2016, Istvan Marko wrote:
> Xapian 1.3 has introduced the DB_RETRY_LOCK flag (Xapian bug
> 275). Detect it in configure and use it if available. With this flag
> commands that need the write lock will wait for their turn instead of
> aborting when it's not
David Edmondson writes:
> Remove "application/zip" from `mm-inlined-types':
>
> (setq mm-inlined-types (remove "application/zip" mm-inlined-types))
Thanks!
Cheers,
Sanel
___
notmuch mailing list
notmuch@notmuchmail.org
Xapian 1.3 has introduced the DB_RETRY_LOCK flag (Xapian bug
275). Detect it in configure and use it if available. With this flag
commands that need the write lock will wait for their turn instead of
aborting when it's not immediately available.
---
configure | 25 -
On Tue, May 03 2016, Sanel Zukan wrote:
> Hi guys,
>
> Pardon me if this question was asked before, is it possible to disable
> automatic preview of zip/archive attachments and keep it toggled as
> hidden?
>
> I often get spam (who does not?) with zip archives and some javascript
> junk, which
Hi guys,
Pardon me if this question was asked before, is it possible to disable
automatic preview of zip/archive attachments and keep it toggled as
hidden?
I often get spam (who does not?) with zip archives and some javascript
junk, which emacs happily open and tries to paint; beside
On Mon, May 02 2016, Mark Walters wrote:
> On Sat, 30 Apr 2016, David Edmondson wrote:
>> `notmuch--get-bodypart-raw' previously assumed that all non-binary MIME
>> parts could be successfully read by assuming that they were UTF-8
>> encoded. This was demonstrated to be wrong,