Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really -attach ]

[Jon Steinhart]

> Jon Steinhart wrote:
> > 2.  Create a program a la configure that scans a target system for programs
> >     that handle content and build the mhshow stuff automatically.  This
> >     can't be hardwired because different things are available on different
> >     target systems.
> 
> Isn't this just reimplementing mailcap? You want to read it at runtime,
> incidentally, because mailcap can be updated as new viewer programs are
> installed. Doing anything at configure time that asks "what binaries are
> installed" is a bad idea because for packages built by distros the answer
> will be "very little in the build environment" and package users could
> have anything at all.
> 
> -- PMM

Well, I really don't want to do it at runtime because of my personal 
preferences.
For example, I have a zillion image viewers on my system but there is one that I
prefer for my mail.  I would hate to have the viewer magically change on me.

I said "a la configure", not "configure".  I was thinking that this could be a
step run as part of install-mh that made some guesses and prompted users when
choices were available.  My notion here was to make it easier for first time
users to get started.

Another approach for this might be to have "fallbacks".  My guess is that 
install-mh
could preload a whole mess of mhshow-suffix stuff as these have more or less 
settled
out over time.  If the mhshow-show stuff could list multiple applications for a 
type
and choose the first one found then that stuff could also be preloaded into the
initial .mh_profile by install-mh.

I'm not the best person to be figuring out how to do this because it isn't a 
problem
for me.  I'm just trying to suggest approaches to addressing some of marcus's 
issues.
In a compatible way, of course :)

Jon