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]

Re: SCWM's embedded docs/text proc benchmarks/perl's 10x faster than guile.


>>>>> "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)