When on tree-style display, any mail whose From: includes full-width
characters will see its tree-style display broken: notmuch mode
apparently assumes that each character is half-width.
For example, japanese characters are not: you can test it by sending
mail from 差出人 or similar characters.
(sorry for sending twice, forgot to Cc the list at first)
I just have been hit by this exact same issue, also for X-GitHub-Sender,
during my switch to notmuch and notmuch-mode.
>> 3) We should think carefully about whether we want to blindly send
>>certain large headers like "Received". Some
Hello!
I've recently (hear: yesterday) switched to emacs' notmuch-mode for mail
handling. So first, thank you for the work you are doing with notmuch,
it's really great!
Now, time for the less-fun stuff: things that were not perfect during
the migration. There weren't many (and the advantages
So this may be an issue that's not worth fixing, but here it comes:
I receive email from people who write HTML emails. And sometimes these
people assume a white background, and write with a hardcoded dark grey
color, which makes everything hard to read.
TBH, I don't think the “solution” of just
David Bremner writes:
> This is needed so that notmuch-wash.el is loadable by itself; in
> particular for the docstring processing.
pushed patches 2 and 3
d
___
notmuch mailing list
notmuch@notmuchmail.org
Daniel Kahn Gillmor writes:
> Without this patch, gcc 8.2.0-7 complains:
>
> debugger.c: In function ‘debugger_is_active’:
> debugger.c:40:24: warning: passing argument 2 to restrict-qualified parameter
> aliases with argument 1 [-Wrestrict]
> if (readlink (buf, buf, sizeof (buf)) != -1 &&
Daniel Kahn Gillmor writes:
> Use explicit labels for GTypeInfo member initializers, rather than
> relying on comments and ordering. This is both easier to read, and
> harder to screw up. This also makes it clear that we're mis-casting
> GObject class initializers for gcc.
>
> Without this
William Casarin writes:
> David Bremner writes:
>
>> William Casarin writes:
>>
>>> Another thought I had that I wanted to throw out there for
>>> consideration. It would be nice to be able to sort by "popular" threads,
>>> aka sort by the number of messages in each thread. Not sure if this is
