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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers