On Sat, 09 Nov 2019, Johan Parin <johanparin@gmail.com> wrote: > Jani Nikula <jani@nikula.org> writes: > >> On Sat, 09 Nov 2019, Johan Parin <johanparin@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)))) > 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. 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 message... BR, Jani. _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch