Re: automatic decode mime in repl

[Ken Hornstein]

>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.

--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