On Tue 2019-11-12 20:24:12 +0100, Johan Parin wrote:
> 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

Yes, and of course i accept that notmuch is a "nerdy" MUA.

> I really don't think the configurability is expensive.

To be clear, i'm suggesting that the code maintenance for the
configurability (and the API surface it creates) is what's expensive,
not that the code is particularly costly to run.

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

Are you sure you want the configuration in the config file and not in
the database itself?  we've had a bunch of discussion on-list about the
fact that the config data is split between the config file and the
database, and some of the config must live in the database (because the
config affects library operations, which do not read the config file).

Eventually, i hope we will consolidate on config-in-the-database, so
each additional piece of config we add to the configfile makes me sad.

furthermore, if we ever decide to remove these configuration options
(e.g. by switching to (a)), we'll end up making some users sad.  so it's
ongoing code maintenance even if most people don't use it :(

And, I still haven't heard any clear arguments for choosing between
configurability as an absolute thing or a differential thing.  They have
significantly different impact on adopters over time, as the default
configuration changes.

So, of the three options you list, i far prefer (a) because it doesn't
introduce any of the configurability maintenance or API complexity
costs.

If the main objection to (a) is performance regression, i'd like to see
some profiling of that performance cost, so we can better understand it.
Perhaps there's a different way to mitigate a performance regression.

          --dkg