Re: [BUG] Custom headers in `notmuch-message-headers` are broken
Jan Malakhovski writes: >> 3) We should think carefully about whether we want to blindly send >>certain large headers like "Received". Some people use notmuch via >>ssh or equivalent, and it might (dunno) be a concern. > > I'd prefer `notmuch show` to dump everything by default and have an > option like `--headers` to limit those. I.e. to get current behavior > you'd just dump comma-separated `notmuch-message-headers` into that > option in `notmuch.el` and be happy. that would be an option, it would require updating the elisp. > >> 1) You'll want to avoid duplicating headers already emitted > > Why? Wouldn't that prevent you from parsing "Received" headers in > `notmuch.el`? I just meant that the code has already emitted e.g. "Cc" by the time it reaches the block Amin points to. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [BUG] Custom headers in `notmuch-message-headers` are broken
> 3) We should think carefully about whether we want to blindly send >certain large headers like "Received". Some people use notmuch via >ssh or equivalent, and it might (dunno) be a concern. I'd prefer `notmuch show` to dump everything by default and have an option like `--headers` to limit those. I.e. to get current behavior you'd just dump comma-separated `notmuch-message-headers` into that option in `notmuch.el` and be happy. > 1) You'll want to avoid duplicating headers already emitted Why? Wouldn't that prevent you from parsing "Received" headers in `notmuch.el`? ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [BUG] Custom headers in `notmuch-message-headers` are broken
Amin Bandali writes:
> I got bitten by this today.
>
> I only had a brief look at the format_headers_sprinter function
> in notmuch-show.c. Would you, David, or anyone else be able to
> point out if the following makes sense, for generalizing
> format_headers_sprinter to handle any arbitrary headers?
>
> I saw this bit near the bottom of that function:
>
> --8<---cut here---start->8---
> if (reply) {
> sp->map_key (sp, "In-reply-to");
> sp->string (sp, g_mime_object_get_header (GMIME_OBJECT (message),
> "In-reply-to"));
>
> sp->map_key (sp, "References");
> sp->string (sp, g_mime_object_get_header (GMIME_OBJECT (message),
> "References"));
> }
> --8<---cut here---end--->8---
>
> So I had a look at GMimeObject's docs on GNOME.org [0], and saw
> g_mime_object_get_header_list, which returns a GMimeHeaderList*
> list of headers [1], which seems to be what we're looking for.
>
> From there, we'd walk over 0..(g_mime_header_list_get_count-1)
> indices and use g_mime_header_list_get_header_at to get each
> header, and pass it to g_mime_header_get_name to get the name
> which we'll pass to sp->map_key and also use to get its value
> from g_mime_object_get_header.
Sounds roughly correct. Note that
1) You'll want to avoid duplicating headers already emitted
2) This will most likely require updating the test suite to add new
headers to the expected output. If that is too burdensome we could
consider bumping the version in devel/schemata, but I'd rather not.
3) We should think carefully about whether we want to blindly send
certain large headers like "Received". Some people use notmuch via
ssh or equivalent, and it might (dunno) be a concern.
4) Your plan _might_ only be working with gmime 3.0+. That's ok, it
just means I would need to finally apply the patches I've got kicking
around removing gmime-2.6 support.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Removing notmuch-wash-excerpt-citations from hook breaks fontlocking
Hello, On Wed 25 Jul 2018 at 04:33PM +0800, David Bremner wrote: > The issue is that the notmuch-wash-cited-text is applied in > notmuch-was-excerpt-citations. A simple solution would be to make > another wash function that did less (only did the overlay application) > and use that. Thank you for your reply. Here is how to get what I wanted when I ran into this bug: ;; don't collapse cited text ;; We ought to be able to just remove ;; `notmuch-wash-excerpt-citations' from ;; `notmuch-show-insert-text/plain-hook', but that function is also ;; responsible for colouring cited text (this is an upstream bug: ;; that function does the colouring for performance reasons but the ;; right answer is to use fontlocking, not overlays, for the colouring) (setq notmuch-wash-citation-lines-prefix 1 notmuch-wash-citation-lines-suffix 1) -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Removing notmuch-wash-excerpt-citations from hook breaks fontlocking
Sean Whitton writes: > > 3. M-x customize-variable notmuch-show-insert-text/plain-hook RET > > 4. Untick notmuch-wash-excerpt-citations > > 5. Open notmuch-show on a message > > Expected result: > > Quoted text is fontlocked, i.e. a different colour to body text. > > Actual result: > > Quoted text is not fontlocked. The issue is that the notmuch-wash-cited-text is applied in notmuch-was-excerpt-citations. A simple solution would be to make another wash function that did less (only did the overlay application) and use that. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
