Hello notmuch,
I noticed something peculiar while hacking on the notmuch Rust bindings.
One of the unit tests, when run through valgrind, consistently produced
this trace:
--8<---cut here---start->8---
==232461== Thread 2 test_tags::mutab:
==232461== Conditiona
Eliza Velasquez writes:
> Is it possible then that there's a potential memory error with removing
> a non-existent tag on a message? I wanted to ask about this on the
> mailing list before diving in deeper, since this isn't quite the latest
> version of notmuch and I wasn't sure if it had been f
David Bremner writes:
> Since notmuch 0.24, notmuch-emacs has overriden the Gnus defaults for
> inlining attachements with type "application/*" when showing
> messages. This series adds some tests and applies the same override
> for reply.
Applied to master.
d
__
A user asked about the thousands separator on IRC, and I had to check
the source.
---
I realized the docstring was getting mangled when auto-translated to
rst, so I did the manual translation.
doc/conf.py | 2 +-
doc/notmuch-emacs.rst | 41 -
2
hgv writes:
>
> I'm still struggling with the Content-Transfer-Encoding header and the
> "charset=utf-8" half of the Content-Type header, both of which I
> cannot get set in my emails, if anyone has any thoughts!
My only (not so helpful) thought is that this almost certainly an issue
outside notm
On Mon, May 16 2022 at 06:47 -03, David Bremner wrote:
> Ideally of course I'd like a reproducer in C. It would help to have
> line numbers in the valgrind output. It might be enough you install the
> notmuch debug symbols?
Took me a while to figure out the debugging workflow in NixOS, but I
ma
Eliza Velasquez writes:
> It becomes very clear why this error only happens when removing a
> non-existent tag if you look at at message.cc:1570...
>
> --8<---cut here---start->8---
> try {
> message->doc.remove_term (term);
> message->modified
Hello David,
admittedly being unfamiliar with the test suite, and not being able to
run the tests at my end, this is a bit of a head scratcher for me. Thus
up-front apologies, and thanks for bearing with me!
David Bremner writes:
> [...]
> It seems that it is mostly working, but there are a few
