I have been trying to stay out of this discussion, as I don't have
time to work on the code, or contribute anything to the implementation,
but I just can't resist the temptation to interfere...
What you're planning doing just isn't the MH way - it is instead the
"obvious" way, the way that seems like things ought to work, and then
without a lot of thought, jumping right into discussions of implementation
trivia, instead of analysing the design, and then doing things the right
way.
The MH way for this, would be for moreproc (and rmmproc, etc) to simply
name a command 9for for whatever apps use them to have command line
override switches to allow those to be overridden), and then when one of
these processes needs to be run, the profile entry for whatever command is
moreproc should be examined for args.
So, if you have
moreproc: less
then when moreproc is needed, we'd look for
less: -p
(or whatever) in the profile, and get the args that way. Then one can
also have
more: -s
in the profile, and when needed run "show -moreproc more" or whatever.
A design like that (perhaps with some refinement) is much more in line with
the MH way of doing things.
Either way, the UI design should be worked out first, and only then should
there be any discussion of the minutia of the implementation details (which
really don't matter much, as it's always possible to just change the
implementation method if a better one comes along - it is much harder to
change the UI once it is advertised.)
kre
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers