[PATCH 2/3] show: output Reply-To headers

[Austin Clements]

Quoth Mark Walters on Jul 05 at  9:47 am:
> On Wed, 04 Jul 2012, Peter Wang <novalazy at gmail.com> wrote:
> > On Tue, 03 Jul 2012 19:22:18 -0700, Jameson Graef Rollins <jrollins at finestructure.net> wrote:
> >> On Tue, Jul 03 2012, Peter Wang <novalazy at gmail.com> wrote:
> >> > I want to see what the sender intended, before hitting reply.
> >> 
> >> Given that there have been requests to see a lot of other headers as
> >> well, we probably need to have a discussion about which ones are worth
> >> of emitting, and how we give the user some more general control to see
> >> the ones they want.  Either that or we just emit them all?
> >
> > If we start with the obvious:
> >
> >   notmuch show --output-headers=date,from,subject,to,cc,reply-to ...
> >
> > with the default being the current set.
> >
> > Emitting everything would be easier but seems wasteful.  I just looked
> > at a random message: in RFC822 syntax the header is 4073 bytes, and the
> > body is 1116 bytes.  Keeping only the fields that notmuch emits reduces
> > the header to 295 bytes.  Reply-To is 92 bytes, but not every message
> > has that.
> 
> I wonder if it would make sense for this option to be combined with
> something like
> id:"1341041595-5858-1-git-send-email-markwalters1009 at gmail.com" which
> chooses whether to output the body of the message or not.
> 
> Maybe something like --output=short|medium|full
> with short being just the brief headers, medium being the current
> default of brief headers and text bodies, and full being message with
> all headers.
> 
> I am not sure I like it (as someone will want full headers and no
> bodies!) but we don't want the command line to get too cluttered.

This option seems like the type of thing that would be used primarily
by frontends, so it matters much more that they have control over the
output than that the command line is terse.  We should provide
reasonable defaults for the occasional flesh and blood call to the
CLI, but I don't think we need to cater to that use.

> Another possibility for this particular choice: could a list of wanted
> headers be included in the config file? Since I think you want it for
> "user wants to see it" reasons rather than "program needs it to do
> something" reasons that might make sense.

This would make a lot of sense in the frontend configuration (so much
so that we already have it!  But it's currently limited to removing
headers).  Also, if it's in the notmuch configuration, then when
programs do need the headers to do something, it becomes very
difficult to request what they need.