[PATCH] Fix format_headers_sprinter to return all headers

[Johan Parin]

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 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.

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))))
	  notmuch-message-headers)

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.

/Johan