[PATCH] Fix format_headers_sprinter to return all headers
jani at nikula.org
Sun Nov 10 01:46:10 PST 2019
On Sat, 09 Nov 2019, Johan Parin <johanparin at gmail.com> wrote:
> Jani Nikula <jani at nikula.org> writes:
>> On Sat, 09 Nov 2019, Johan Parin <johanparin at gmail.com> wrote:
>>> Modify format_headers_sprinter so that it returns all headers in the
>>> sexp, instead of a fixed set of headers.
>> I have to deal with plenty of long threads that already take a very
>> long time to open in notmuch-emacs. How's this going to impact the
>> emacs interface performance? For example the patch mail I'm replying
>> to has more header content than body content. There are tons of
>> headers that I can't imagine being useful to anyone.
> How long are these threads may I ask? Would it be possible for you to
> apply the patch and see if you see a noticable difference?
I'll need to try this with my work email which is the bigger problem.
> I have a hard time seeing that the C code would cause any noticable
> performance impact, but perhaps the elisp. But my general understanding
> of the code base is low, so I may be wrong.
It's indeed the lisp part that I'm worried about.
> I guess it's in the following type of code the performance concern lies?
> (mapc (lambda (header)
> (let* ((header-symbol (intern (concat ":" header)))
> (header-value (plist-get headers header-symbol)))
> (if (and header-value
> (not (string-equal "" header-value)))
> (notmuch-show-insert-header header header-value))))
> Don't know how efficient plists are in general.
>> I'm wondering if the right thing to do would be to make it possible to
>> specify which additional headers to include in notmuch-show
>> output. This would be based on notmuch-message-headers. We already
>> have options to include/exclude body content and html parts for much
>> the same reasons. (Though the command-line arguments for those are
>> incoherent at best.)
> This would be possible of course.
> Another option I guess is to hard code some extra "interesting"
> headers. But what is interesting is subjective and it is very nice to
> have the flexibility to control this is in elisp.
> mu4e has the customization variable `mu4e-view-fields', but it can only
> take on values from a restricted list, namely:
> :from :to :cc :subject :flags :date :maildir :mailing-list :tags
> :attachments :signature :decryption :user-agent
> So a compromise would be to restrict the returned headers to a list like
> this. This of course is if we think the potential performance issue is
> in the elisp.
> Personally I would be content for the moment to be able to see
> user-agent and x-mailer. But that's just me.
I failed to mention that I do think the feature itself would be useful
and welcome. Currently I just hit V and find the header in the raw
More information about the notmuch