Es schrieb Dan Kegel: > > Guido Draheim wrote: > > > > overkill. > > Agreed. I'm tempted to say: > Death to XML, long live *plain* text! > it's not quite xml that's bugging me - it's that the intelligence needed to form a good html view is put on the creator of the macro. Simon(s) says, that the current extraction of information out of the dnl-header is not very good in order to get a good html view - this is true. But my answer would be to add more intelligence into the extractor with more options that writers of dnl-headers can use to optimize the output, possibly with optional xml-tags thrown in some of the time - as part of the dnl-commentblock, not around it.
Since gnu ac-archive drifts into xml buzzword space, I will probably take the opportunity to throw away Simons' macro2html.cpp that is currently used, and build a perl script for the sf-net ac-archive that will have atleast the extracting and report generation intelligence of the c++ binary - I have to admit that I find it easier to add extra intelligence into a script made in a Practical Extraction and Report Language rather than in C++, but that has to wait a bit since I am busy with other stuff. Anyway, let's see what the Simons' efforts will finally bring about - I must say to be quite interested to see what the experiences with such a setup will be, since I am doing quite some xml stuff as part of my daily life, but in there I value it more as the intermediate computer- written almost-human-readable data-representation instead of a user-written input and user-oriented output format. Anyway, perhaps such a perl-based script that converts macro-dnl-commentblock to xml/html-doc-pages, could be also used for plain autoconf, but that's a second step I guess, as there is much more complexity in that. cheers, guido
