HI,
I was wondering if it was possible to add the text extracted from an
attachment to the search index?
For the moment let's leave aside the important issues like - security,
buffer overflows, clients having to install
doc2text/pandoc/pdftotext/whatever...
I *think* I'm trying to ask - How can
David Bremner writes:
> Sebastian Schwarz writes:
>
>> Allow me add to this RFE.
>>
>> On 2017-02-28, Steven Allen wrote:
>>> Currently, notmuch fetches keys synchronously. This can be
>>> *very* slow (I fetch keys over tor) and locks up emacs for the
>>> duration. Therefore, this fetch really
Daniel Kahn Gillmor writes:
> On Mon 2017-02-27 16:26:50 -0800, David Bremner wrote:
>> We already use this directory for dtach sockets, so it makes sense to
>> put gnupg sockets there as well. There doesn't seem to be a clean way
>> to put a fully functional socket in a different location than
>
David Bremner writes:
> David Bremner writes:
>
>> I haven't had a chance to really track this down, but it seems there is
>> a memory error in notmuch new (or a maybe false positive from valgrind).
>>
>> Attached is the log from running "make memory-test OPTIONS=--medium" on
>> current git mast
On Tue 2017-02-28 12:35:05 -0800, Steven Allen wrote:
> Currently, notmuch fetches keys synchronously. This can be *very* slow
> (I fetch keys over tor) and locks up emacs for the duration. Therefore,
> this fetch really should be asynchronous.
>
> Unfortunately, getting this to work well (i.e. not
On Mon 2017-02-27 16:26:50 -0800, David Bremner wrote:
> We already use this directory for dtach sockets, so it makes sense to
> put gnupg sockets there as well. There doesn't seem to be a clean way
> to put a fully functional socket in a different location than
> GNUPGHOME.
LGTM. Thanks for wran
Where to obtain notmuch 0.23.7
===
https://notmuchmail.org/releases/notmuch-0.23.7.tar.gz
Which can be verified with:
https://notmuchmail.org/releases/notmuch-0.23.7.tar.gz.sha1
07eca222977488051cb7fcd3f2238da355c5ec1c notmuch-0.23.7.tar.gz
https://notmuchmail.or
Sebastian Schwarz writes:
> Allow me add to this RFE.
>
> On 2017-02-28, Steven Allen wrote:
>> Currently, notmuch fetches keys synchronously. This can be
>> *very* slow (I fetch keys over tor) and locks up emacs for the
>> duration. Therefore, this fetch really should be
>> asynchronous.
>
> E
Allow me add to this RFE.
On 2017-02-28, Steven Allen wrote:
> Currently, notmuch fetches keys synchronously. This can be
> *very* slow (I fetch keys over tor) and locks up emacs for the
> duration. Therefore, this fetch really should be
> asynchronous.
Even with all keys already present signat
Currently, notmuch fetches keys synchronously. This can be *very* slow
(I fetch keys over tor) and locks up emacs for the duration. Therefore,
this fetch really should be asynchronous.
Unfortunately, getting this to work well (i.e. not interleave output in
the `*notmuch-crypto-gpg-out*` buffer) r
On Tue, Feb 28 2017, David Bremner wrote:
> We already use this directory for dtach sockets, so it makes sense to
> put gnupg sockets there as well. There doesn't seem to be a clean way
> to put a fully functional socket in a different location than
> GNUPGHOME.
> ---
LGTM.
Tomi
> test/test-l
Jani Nikula writes:
> The help command does not really need to try to open the config
> file. So don't.
series pushed to master
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Jani Nikula writes:
> Reduce duplication in follow-up work. As a side effect, handle error
> returns from g_mime_content_disposition_get_disposition() without
> segfaulting.
Series pushed to master
___
notmuch mailing list
notmuch@notmuchmail.org
https
13 matches
Mail list logo