Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes: > On Mon 2019-11-11 10:26:18 -0500, Daniel Kahn Gillmor wrote: >> - What is the specific use case for this? For example, can you identify >> situations where different headers need to be emitted by different >> users? Even one motivating example would help others on this list >> understand why they might want to care :) > > ah, sorry, i've just read > id:20191109221358.4349-1-johan.parin@gmail.com and its associated > messages, so i can see that some of the questions i'm asking are > already under discussion. > > I see that you just want user-agent and x-mailer for your own > purposes. > Well that is just my current minimum requirements. I'm a mail nerd and I always want to see what mua people are using, if present. And no, it is not OK to have to hit 'V' and see all headers. There are way too many garbage headers. You want to have the headers you are interested in to be displayed automatically for every message in a nice readable fashion. Someone else in this thread wanted Arhive-At; the bug reporter wanted X-Github-Sender. Now that I think about it I definitely want X-Face. Maybe List-Id. etc. It's really hard to predict what people think is interesting, which is why configurability is needed. I think this is quite basic functionality. All "nerdy" muas have it ;) Gnus has it, mu4e has it etc. mutt seems to have some reasonable default of at least displaying User-Agent. I think Thunderbird has it too. etc > Maybe it would be worthwhile to propose that narrow, limited change as > a simple patch, without configurability and see what it looks like? I > would personally be more likely to advocate for merging a patch that > meets the specific needs of a notmuch user, and increase the > configurability surface of notmuch. > I really don't think the configurability is expensive. The elisp code base is already prepared for it with the notmuch-message-headers variable. It's just that it's not working because notmuch-show.c only exports a fixed set of headers. So it's a bug fix, really. > If processing a couple of extra headers on a long thread is too > expensive for some consumer, i'd suggest that is an optimization for > the consumer to tackle. I have implemented three variants: a) notmuch-show.c exports all headers b) notmuch-show.c exports a limited set of "interesting" headers. This patch should be modified to set the headers in the config file. I think this is a really good solution if you are concerned with performance in a) c) notmuch-show.c exports headers specified with a command line arg, which is passed from the elisp based on `notmuch-message-headers'. In all cases the actual headers displayed in the emacs mua is controlled by `notmuch-message-headers'. Personally I don't think there is any discernible performance impact with any of these, and that any performance impact is dwarfed by the GMime message parsing code and elisp display code. But if there is concern with a, then b) and c) can be chosen which should have basically zero performance impact. I also don't think there is maintenance cost with any of these once it is implemented so I don't see why we should not have configurability. All of the patches need some polishing (and I noticed a functional issue with "c). But if we can get consensus on an approach that is OK, then I would be happy to continue perfecting it. /Johan _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch