This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>>>>> "Perry" == Perry E Metzger <perry@piermont.com> writes: Perry> Better to stick to the Docbook DTD in my opinion, and produce a more Perry> general tool to create TeXinfo from the SGML. There is a reason lots Perry> of people are moving towards using the Docbook based tools. I must admit that all this talking about SGML make me feel a little uneasy. I can understand why SGML is appealing for a number of reasons, but I am not sure that this route is the good one for us, and certainly not for what I would like to see happen (bias warning: I am a long time TeX/TeXinfo fan). There are two sides to the discussion: an output side and an input side. What do we want to distribute to endusers and what do we want to generate as input to the distribution process. Let me start by the output side. I think we should generate info files. It is widely used in the free software community, even a defacto standard perhaps, certainly more so for the FSF line. I also like typical info readers a lot better than typical web readers. It also appears to me that getting a working SGML system going on your machine is somewhat involved. When the discussion started on the SCWM list, somebody posted a 10+ list of packages one needed. As usual, the linux community has no problem, since SGML support comes prepackaged in all major distributions, but we need to think beyond linux. Now the input side. In principle, the extractor could generate anything that could be used to produce the above info files (plus other formats as well). Apparently the SGML tools isn't quite there yet. We could write such a tool, but our ressources are limited and could be better spent in getting the extractor done and improving the documentation. Presumably, changing an existing extractor to generate SGML rather than TeXinfo is as easy (my guess: a lot easier) than to write the tool to convert SGML to info. Here I am focusing only on *extracted* documentation, ie. markup generated automatically. The situation changes when we are talking about actively writing markup. Here the case for DocBook is stronger, and once a decision is made, it gets much harder to change. Those writing the manuals can do whatever they feel like, but we need to decide whether documentation strings (those that are extracted) can contain markup or not. [if this discussion already has been decided, I apologize for the waste of bandwidth. I know it has been discussed.] If the answer is no (there will be some textual convetions of course), there really isn't any problem IMO. The extractor will be easy to change. I think we should stick with the no. I would like to see a system that has a hope of working without fullblown markup engines, even on a dumb command-line. We also need to keep the whole process simple for our own good. ---------------------------+-------------------------------------------------- Christian Lynbech | Telebit Communications A/S Fax: +45 8628 8186 | Fabrik 11, DK-8260 Viby J Phone: +45 8628 8177 + 28 | email: chl@tbit.dk --- URL: http://www.telebit.dk ---------------------------+-------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic)