Re: automatic decode mime in repl

[Philipp Takacs]

[2022-02-11 02:55] David Levine <levinedl@acm.org>
> Philipp wrote:
>
> > Hi David
> >
> > I don't understand why do you try to convince me from convertargs.
>
> I'm not trying to convince you of anything.  I'm trying to understand
> how nmh could benefit from your patch.  And whether your approach could
> be improved by tying it to features that are already in repl (and that
> you weren't aware of when you wrote the patch).  And whether your patch
> interferes with existing repl features.  And what are both intended and
> unintended uses of the new feature.

Ok sorry then I missunderstand your request.

> To clear up some things:
[ ... ]
>
> * Your nmh installation is broken, as you observed.  I expect that the
>   cause was deleting par after nmh was installed.  The test suite did
>   the right thing by alerting you to the deficiency.  We could guide
>   you through (easy) repair of your installation, but I would instead
>   suggest a complete rebuild, if you built from sources, or re-install
>   if you obtained a pre-built package.

I think you miss a big point point, I don't have nmh. I have _m_mh.

All I did was clone the repo, build it and run ``make check''. The
hole time ``par'' wasn't installed. The build creates etc/mhn.defaults
with the wrong mhbuild-convert-text entry.

> And whether your approach could be improved by tying it to features
> that are already in repl (and that you weren't aware of when you wrote
> the patch).

As a _m_mh user I don't have the -convertargs switch. And I don't see
why I need it. It looks like the -convertargs switch and the convert
interface are only there to allow repl decoding mime.

But to decode mime messages there is a feature in nmh which was there
before convertargs: mhshow. All my patch does is call mhshow and pipe
the mail through it. Nothing more and nothing less. By this way you
get mhshow to decode mime and all of it's features.

convertargs is a diffrent aproatch, therefor I don't see a way to
improve my patch by using convertargs.

> And whether your patch interferes with existing repl features.

The -convertargs switch still works, because it is used with the filter
mhl.replywithoutbody. With the -mime switch you wont even hit the
coresponding code path. I don't see any possible interferes with other
repl features.

With other workarounds there may some problems. I would asume most will
just work, because they should also work on non mime mails.

> And what are both intended and unintended uses of the new feature.

Intendet is to make repl -fixmime be able to reply to a mime message.

Unintendet is that repl may start a videoplayer, if there is a video in
the message (or start some other graphical programms).

> I'm trying to understand how nmh could benefit from your patch.

Have an easy to use, enable by default and sane way to reply to mime
messages.

Under a easy to use and enable by default solution I understand something
the user needs at most one switch to use this in a sane way. No aliases
or editing of the profile, no requirement to manuall call mhbuild (or
anything else) and no convenience shell file with aliases.

> > The question is: Do you want it?
>
> Not with its current handling of URLs.  How do you handle URLs in
> messages that you reply to?

This patch doesn't handle URLs at all. mhshow will print them as is to
stdout. After that mhl will add the '> ' and linebreaks. As said in the
other mail, this is the default behavior of repl. This has nothing to do
with my patch. There where already two ways mentioned in this thread how
this could be fixed.

Philipp