Re: [Nmh-workers] nmh not using w3n or elinks

[Ken Hornstein]

>this may well be a good idea, but it feels like much of norm's problem
>was that the relevant configuration is done at build time.  if the
>default mhshow-show-text/html entry pointed to a helper script, rather
>than to a specific browser, that script could search for and run an
>appropriate browser at run-time, probably using the same list we
>currently look through at build time.

Sigh.  I personally viewed the default configuration as something that
should be servicible, but open to tweaking.  As I read it, the issue
wasn't that Norm wasn't open to adding stuff to his configuration, it
was more that he didn't want to deviate from the out of the box setup,
for reasons I will admit I didn't understand.  Also, I didn't really
understand the problem with lynx; if it plain didn't work, that's a bug
that we should fix.

It does occur to me that perhaps the most sensible thing is to leave
the non-working entries in the mhn.defaults, but commented out.  That
makes it easy to see something that we presume would work.

>(how do pre-built nmh packages handle this?  simply with dependencies
>on the necessary text browsers?  if we were to provide our own simple
>renderer as lyndon suggests, those dependencies could become
>suggestions.)

The packages that include builds from source obviously get those at
build time.  The RPM packaging ... hm.  It looks like it would just
use whatever is available on the package builder's system.  There are no
dependencies on text browers.

--Ken