nmh-workers
[Top] [All Lists]

Re: automatic decode mime in repl

2022-02-08 04:31:16
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.


<Prev in Thread] Current Thread [Next in Thread>