On 14 Mar 2009 15:34:52 +0000, Thomas Adam wrote: > > 2009/3/14 Mikhael Goikhman <m...@homemail.com>: > > [...] > > > One of the examples of a pragmatical asciidoc that may be considered is > > POD (Plain_Old_Documentation article in Wikipadia). Well, all perl > > documentation in fvwm is already in POD, and the corresponding html is > > generated from it. > > That's one possibility but very inflexible. No, we're talking about > the manpage here -- and I wouldn't want to see POD used as a basis for > it. I use POD on a daily basis; it's fine for perl and perl-related > things, but as a generic markup for plain text for other documentation > purposes, forget it.
I would never force POD myself although some people write whole books in it... My point was just to demonstrate two text-based formats of my choice that are designed to be convertable to HTML and Latex. > > Another example of asciidoc I use in my non-fvwm related projects is > > wikitext (Text::WikiText on CPAN to be more specific, maintained by me). > > > >> I'm just wary of (excuse my language here) pissing over the people who > >> put so much effort into the current docbook stuff. > > > > Exactly the same feelings. > > My webshite (sic) uses txt2tags [1] which has some advantages over > asciidoc in that the markup is a little simpler, and unlike asciidoc, > doesn't impose certain restrictions for templates (which expose > limitations in docbook itself). > > I'm going to bite the bullet and after having finalised > fvwm-convert-2.6 (which is all but done for review -- hopefully by the > end of this weekend) I will turn my attentions to looking at what we > might do about the documentation process [2]. I suggest you to show the whole specs before you start this work, and to get at least the Dominik's approval, so this work is not lost again. In any case I prefer others to decide on the documentation source format. For some reason I was under impression Dominik approved the docbook thingy before it was implemented or at least had no objection to it... Regards, Mikhael.