Re: automatic decode mime in repl

[Philipp Takacs]

Hi

[2022-02-07 16:54] Ralph Corderoy <ralph@inputplus.co.uk>
> > Instand of only depending on the programm name the config can be
> > extended to also depend on the calling programm. So you can config
> > diffrent options depending on which nmh programm called another nmh
> > programm. This could be done by (ab)using argv[0].
>
> Adding yet another style of interface between nmh's parts, which would
> have to be documented and users would have to understand and use, seems
> wrong.  What's your reason against running mhshow as ‘mhreplyfmt’, or
> something?  Is it the need to duplicate all MIME-configuration entries
> from ‘mhshow-*’ to ‘mhreplyfmt-*’?

The duplication is the one thing. The other thing is I would like to
extend the existing configuration system. Yes you can run mhshow as
`mhrelyfmt', but there is no logic behind the choice of argv[0]. The
idea was to define such a logic and use it to make the config more
powerfull.

As an exaple it could be possible to have diffrent showmimeproc config
for a `replA' and a `replB'. Or what about a diffrent sendmail or even
another path?

Yes this is a big change and way beound this patch. This might be as far
in the future as implementing MIME for mhl. Start with smaller fix like
setting argv[0] to `mhreplyfmt' is perfect fine.

> > * mhshow display string can contain '%l' which leads to a listing
> > prior to displaying content. This listing is contained in the draft.
>
> Again, the mhreplyfmt-... could choose whether to use it.  I think
> I would sometimes want it as part of the reply text, e.g. it's a
> one-line summary of a PDF and I want to quote that line for context
> about my following chunk of reply.

I have never thought[0] about solving this in this way. Yes this will
also work. In general I'm not a big fan of the '%l' and would prefer
one switch instand of '%l', but this is another discussion.

Philipp

[0] Mostly because of small diffrences between mmh and nmh.