Doug McIlroy <d...@cs.dartmouth.edu>:
> I agree that good candidates for updating the man macros are likely
> to be found among the readership of this mailing list. However,
> the biggest problem with man pages is that people don't write them.
> groff_mom(7) is a recent example--all it does is point somewhere
> else. The biggest culprit is info--a maddeningly archaic facility
> to which Gnu clings tenaciously. Unless it can be foreseen how new
> man macros would displace texinfo from its throne, the exercise
> will largely be in vain.
I'm working this problem. I don't think I can kill info with groff,
but RMS and I have an agreement in principle to work towards killing
it with asciidoc (which can generate manual pages).
> While a to-do list is on the table, is there anything that needs
> to be done for eqn, tbl, pic, and other preprocessors?
I'm also paying attention to this. I wrote pic.ms, which is the most
detailed user's guide for any version of pic; I continue to be
interested in keeping pic alive. I also taught geqn to emit MathML.
Based on those experiences, the main feature I think all these
preprocessors need (in particular, to be useful for Web work) is a
font-specification mechanism more general and less crude than groff
\f escapes.
pic should be taught to emit SVG. There is a third-party pic
workalike that does this, so it's certainly possible.
> In pic, the thing I miss most is polygons (preferably allowing arcs
> and splines as edges) that can be filled. After that, the next step
> is a big one: lightweight constraint-based drawing; Van Wyk's Ideal
> (SIGPLAN Notices 16:6) is a proof of concept. Can that be gracefully
> folded into the current pic model?
Maybe. Is there an open-source implementation I can look at?
> Speaking of macros, is there any hope of reconciling the macro
> schemes of groff, pic, and eqn? Or is it obviously silly to try?
I don't understand what you mean by this.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
