Re: automatic decode mime in repl

[Philipp Takacs]

[2022-02-05 22:19] Ken Hornstein <kenh@pobox.com>
> >Reply to mime messages is an old problem. I have an idea to workaround
> >or fix this. Instand of adding mime to mhl, repl could also first decode
> >mime before pipe the mail to mhl. This can be done by mhshow.
> >
> >I have attached a patch for this.
>
> From a purely architectural perspective, I think that having mhl be
> MIME-aware is the correct solution.  But I must acknowledge the reality
> on the ground:
>
> - This has been a problem for a very long time
>
> - Stopgap solutions (like replyfilter) have not made much headway, because
>   they require end-user configuration.
>
> - Getting a MIME-aware mhl (really, all of nmh) is a huge job.
>
> - I believe "perfect is the enemy of the good".
>
> My only concern with this patch is that it unilaterally overrides the
> existing behavior, and one thing I've seen over the years is that there
> are a LOT of users wedded to existing behavior.  So I'd rather make it
> selectable (I am neutral about it being default or not).  I'd welcome
> discussion on this issue.

I can understand that a changed behavior is a problem. But in this case
I would argue there is no other way. Every patch witch tries to fix this
will change the existing behavior, because the existing behavior is the
problem.

So I would prefer no option. But if you want one, I can add an option.
I would prefer the new behavior be the default. Also I would prefer a
build time option over a runtime option. I'm bad at naming, has someone
an idea for the name of such an option.

An alternativ would be to depend on fmtproc. When fmtproc is set don't
pipe through mhshow. When it is not set pipe through mhshow.

Philipp

> --Ken
>
> >This approatch has currently two problems:
> >
> >* mhshow can be configured to display parts in a graphical programm. This
> >  can lead to unexpected behavior on repl (i.e. start plaing musik).
> >
> >I belive there are two options to fixed this problem. First the -textonly
> >swtich can be used. In some probably uncommon setups (i.e. text to speech)
> >this still can lead to problems.
> >
> >The secound option is a bit more complex. 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].
> >
> >* mhshow display string can contain '%l' which leads to a listing prior
> >  to displaying content. This listing is contained in the draft.
> >
> >To fix this I would suggest to remove the '%l' from the display string
> >escapes and create a switch for that. Then you can't enable/disable this
> >per part.
> >
> >What do you think about this patch? Did I missed some problems?
> >
> >Philipp
> >
> >>> text/x-diff content