From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 130026DE0F9A for ; Thu, 14 Nov 2019 12:44:38 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[AWL=-0.252, SPF_NEUTRAL=0.652] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtPdOSAj50uh for ; Thu, 14 Nov 2019 12:44:35 -0800 (PST) Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) by arlo.cworth.org (Postfix) with ESMTP id A37C66DE0196 for ; Thu, 14 Nov 2019 12:44:34 -0800 (PST) Received: from guru.guru-group.fi (localhost [IPv6:::1]) by guru.guru-group.fi (Postfix) with ESMTP id 6C8331000B0 for ; Thu, 14 Nov 2019 22:44:32 +0200 (EET) From: Tomi Ollila To: notmuch@notmuchmail.org Subject: Re: [PATCH] Add --message-headers flag to notmuch-show In-Reply-To: <87pnhvnw4i.fsf@fifthhorseman.net> References: <20191110124929.21903-1-johan.parin@gmail.com> <874kzatox1.fsf@fifthhorseman.net> <87y2wms9r4.fsf@fifthhorseman.net> <87a790pwke.fsf@fifthhorseman.net> <87pnhvnw4i.fsf@fifthhorseman.net> User-Agent: Notmuch/0.28.3+84~g41389bb (https://notmuchmail.org) Emacs/25.2.1 (x86_64-unknown-linux-gnu) X-Face: HhBM'cA~ MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 20:44:38 -0000 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