Re: [PATCH] Add --message-headers flag to notmuch-show

[Tomi Ollila <tomi.ollila@iki.fi>]

On Thu, Nov 14 2019, Daniel Kahn Gillmor wrote:

> On Wed 2019-11-13 01:30:50 +0200, Tomi Ollila wrote:
>> On Tue, Nov 12 2019, Daniel Kahn Gillmor wrote:
>>
>>> 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.
>>
>> I don't understand your question,
>
> configurability as an absolute thing:
>
>  --message-headers=foo,bar,baz
>
> configurability as a differential thing:
>
>   --add-message-header=foo --suppress-message-header=qux

Ahh...

Osmo A. Wiio was a smart man when he stated: "Communication usually fails,
except by accident" ( http://jkorpela.fi/wiio.html - read it now, I'll wait ).

I understand 'configurability' a bit different way -- store something
somewhere which is fetched in the future and alters behaviuor in that
way.

In above options, --message-headers and so on, I'd just "state" or "demand"
the program in question to give me this information, and don't think there
was any configurability in question ('configuration', in "broader" sense,
is there, just hiding somewhere in background =D)

>
>> but I think that configuration option
>> for choosing what message headers to return is far worst of the options,
>> mostly because configuration and what frontend may desire goes easily
>> out if sync (and when managed manually that is what inevitably will
>> happen). 
>
> totally agreed, but this is very different from what you said next:
>
>> The option (b) is kinda my favorite, code could be pretty simple, ordering
>> (sprinted in order listed), duplicates (rescan request list so far and drop
>> if header found) might be the harders questions (and seemed not ;/). 
>>
>> If option (b) were taken, status quo -- no change in returned headers
>> should be maintained -- separate patch series w/ devel/schemata and test
>> changes can be sent is there desire for changing that.
>
> afaict, option (b) seems to contemplate configurability, which you say
> above you don't want.  Maybe we need a clearer list of options, because
> this is getting confusing :P

Perhaps my explanation above cleared at least a bit of confusion.

W/ all this information, somewhat exhaustive (not by options, but by
resources I put making it) list of thougts.


1a by default behave as it is behaving now

1b alternative, in json and sexp, include *all* headers for the use of
   frontends (in many other email systems frontends parse full email
   messages and see all headers, in notmuch case frontends don't have
   to do so since notmuch did the parsing and provides structured data
   of (currently subset) that information


2a have option --message-headers= -- when used just those headers requested
   is returned (I'd personally prefer this over the "differential" options,
   frontends get exactly what it wants and does not need to consider any
   default where to add of suppress from)

2b have --add-message-header=foo --suppress-message-header=qux -- to modify
   the defult list...

2c have named stored configurations, which can be retrieved with yet another
   command line option, since naming is hard, quick potenttially dumb
   example could be like: --custom-message-headers=my-cli-headers-set-3

I personally would first go with 1a and 2a. 2c sounds interesting but
requires more work (and I could personally use wrapper instead =D)

Anyway, if someone(tm) implements any of these, speed is not a problem, and
code is reasonably maintainable happy to see notmuch improved this way...

>
>       --dkg

Tomi