From: Rudi S. <ru...@co...> - 2004-03-24 13:20:29
Attachments:
PGP.sig
|
Hi, So, I was starting to port the debugger chapter of the cmucl manual to sbcl, and became aware of a few things: - With all of DocBook's kajillion tags, function definitions in the sbcl manual are still wrapped in simple <synopsis></synopsis> tags, with the explanation body as simple <para> elements afterwards. And some amount of browsing "DocBook: the Definitive Guide" didn't help me find a better way to sanely mark up a function documentation. - Editing DocBook is unfun; I got stuck halfway through the chapter. This is contrary to my recent experiences with texinfo (http://constantly.at/lisp/asdf/ and http://constantly.at/lisp/asdf-install/): editing these was a pleasure; the markup didn't get in the way, the results were half-decent looking (both pdf and html, and I didn't even start playing with css), and the tools were already installed and working. Now, texinfo has its weak spots (no support for graphics, the tag set is somewhat geared towards Emacs and the elisp manual), but the sbcl manual doesn't have graphics anyway, and, well, documenting a Lisp system is what we (I) want to do here anyway. (Besides, makeinfo can produce basic xml or docbook output, too.) I'd like to volunteer translating the manual into texinfo. Are there any reasons not to? Cheers, Rudi |
From: William H. N. <wil...@ai...> - 2004-03-24 15:16:59
|
On Wed, Mar 24, 2004 at 02:20:05PM +0100, Rudi Schlatte wrote: > So, I was starting to port the debugger chapter of the cmucl manual to > sbcl, and became aware of a few things: > > - With all of DocBook's kajillion tags, function definitions in the > sbcl manual are still wrapped in simple <synopsis></synopsis> tags, > with the explanation body as simple <para> elements afterwards. And > some amount of browsing "DocBook: the Definitive Guide" didn't help me > find a better way to sanely mark up a function documentation. I have also been surprised to find how clumsy the huge tagset can be for plausible-sounding tasks. I suspect that to some extent this is a fundamental consequence of how ontologies are harder to write and maintain than almost anyone realizes until they try to do it, so semantic markup is naturally clumsier than it seems it ought to be. But maybe either a better design at the same level, or a design which gave up on some of the ambitions about semantic markup, could be easier to work with. (I don't know enough about texinfo to have an opinion about the specific comparison to it.) > - Editing DocBook is unfun; I got stuck halfway through the chapter. Granted it's unfun, but for me it's not that much of an obstacle compared to the unavoidable difficulties of writing useful text and keeping it up to date. From what I've heard from other people on this project and others, I'd guess that no one loves it but your reaction to it is rather more intense than usual. > This is contrary to my recent experiences with texinfo > (http://constantly.at/lisp/asdf/ and > http://constantly.at/lisp/asdf-install/): editing these was a pleasure; > the markup didn't get in the way, the results were half-decent looking > (both pdf and html, and I didn't even start playing with css), and the > tools were already installed and working. > > Now, texinfo has its weak spots (no support for graphics, the tag set > is somewhat geared towards Emacs and the elisp manual), but the sbcl > manual doesn't have graphics anyway, and, well, documenting a Lisp > system is what we (I) want to do here anyway. (Besides, makeinfo can > produce basic xml or docbook output, too.) > > I'd like to volunteer translating the manual into texinfo. Are there > any reasons not to? Your volunteering offer does a lot to overcome any resistance that would follow from sheer inertia, but I'm still pretty skeptical about the idea. Besides my remarks above, -- I find it comforting that apparently DocBook is a usable format for writing complete books. My impression is that it would be awkward to do that in texinfo. -- My impression is that DocBook is more widely used. (This isn't actually much of an argument against texinfo, since it's also sufficiently widely used that it should be reasonably convenient. It's more an argument against some hypothetical third choice which might come up.) On the other hand, there's one argument against DocBook which you didn't mention except in passing ("tools were already installed and working"). My biggest frustration with DocBook is that the tools required to translate it are so elaborate and fiddly that it seems to be hard to make it completely routine to build it. It seemed to take a long time before it became mostly routine to be able to build DocBook on major distributions, and even now de facto portability requires a lot of knowledge of OS-dependent file locations. I don't think the SBCL manual requires anything but the plainest, most vanilla DocBook, so I would've hoped that building it could be as simple (from the end-user point of view, after the OS maintainers finish setting up all the file locations) as the analogous LaTeX "latex manual.tex". Instead, DocBook "hello world" seems to involve our doc/Makefile and doc/catalogs/*.xml, >100 lines of stuff to hack on (which at the moment happens to need some kind of hack to autodetect and handle the OS=debian-old case which exists on my laptop). I'm pretty sure that I could work with either system; I don't see killer advantages one way or another. Your strong negative reaction to DocBook could be considered a killer advantage, of course, and if other developers have had similar reactions before but just didn't speak up, they'd probably convince me to switch if they start speaking up now. But just from what I've seen and heard so far -- and guessing that the other developers mostly don't find the DocBook they know to be much more frustrating than the texinfo they know not of -- my inclination is to remain with DocBook despite your offer to convert to texinfo. (Two more arguments to try if you're sufficiently frustrated: (1) find a multideveloper project or two which switched to texinfo and has written up a summary of why in retrospect it was a good decision, and/or (2) convert 200 lines or so of text more or less cribbed from the existing manual from DocBook to texinfo, with foo-in-texinfo.texinfo, foo-in-docbook.xml, foo.html-as-converted-by-texinfo, foo.html-as-converted-by-docbook, and possibly some other output format you think would be convincing; then send the resulting wouldnt-you-rather-work-with-texinfo.tar file to the list.) -- William Harold Newman <wil...@ai...> to make it simpler, he cut out lots of ono-essential stuff -- dan_b explaining SBCL on #lisp PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Luke G. <lu...@bl...> - 2004-03-24 15:44:39
|
William Harold Newman <wil...@ai...> writes: > Your volunteering offer does a lot to overcome any resistance that > would follow from sheer inertia, but I'm still pretty skeptical about > the idea. Besides my remarks above, > -- I find it comforting that apparently DocBook is a usable format for > writing complete books. My impression is that it would be awkward > to do that in texinfo. The GNU folks do sell quite attractive hardcopy-book versions of the same manuals in the info directory. I don't know if it's awkward for them or not, though. A nice example is the texinfo manual (written in texinfo) formatted in PDF: http://www.gnu.org/software/texinfo/manual/texinfo/texinfo.pdf > -- My impression is that DocBook is more widely used. (This isn't > actually much of an argument against texinfo, since it's also > sufficiently widely used that it should be reasonably convenient. > It's more an argument against some hypothetical third choice > which might come up.) I don't know about this, but running 'info' on a GNU box does show quite a few programs using texinfo. P.S., texinfo does have simple support for images, at least in recent versions. -Luke |
From: Julian S. <der...@we...> - 2004-03-24 17:38:44
|
William Harold Newman <wil...@ai...> writes: > -- I find it comforting that apparently DocBook is a usable format for > writing complete books. My impression is that it would be awkward > to do that in texinfo. I have a 600+ pages book in front of me typesetted using texinfo and it looks ... mhhh ... like a normal book to me. (It is about TCP/IP if any one is interested.) > -- My impression is that DocBook is more widely used. (This isn't > actually much of an argument against texinfo, since it's also > sufficiently widely used that it should be reasonably convenient. > It's more an argument against some hypothetical third choice > which might come up.) Using texinfo would reduce the build dependencies of SBCL. Ok, the point is that IMHO more people have texinfo on their system than docbook and friends.=20 Regards, =2D-=20 Julian Stecklina Key-ID: 0xD65B2AB5 FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5 "I meant," said Iplsore bitterly, "what is there in=20 this world that makes living worthwhile?" Death=20 thought about it. "CATS," he said eventually, "CATS=20 ARE NICE." - Terry Pratchett, Sourcery |
From: Paolo A. <am...@mc...> - 2004-03-24 19:15:22
|
William Harold Newman <wil...@ai...> writes: > -- I find it comforting that apparently DocBook is a usable format for > writing complete books. My impression is that it would be awkward > to do that in texinfo. The printed version of the Emacs manual has about 400 pages, the Emacs Lisp manual more than 600. Both are in Texinfo format. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film |
From: Rudi S. <ru...@co...> - 2004-03-25 07:03:01
Attachments:
PGP.sig
|
On 24. M=E4r 2004, at 16:15, William Harold Newman wrote: > On Wed, Mar 24, 2004 at 02:20:05PM +0100, Rudi Schlatte wrote: > >> I'd like to volunteer translating the manual into texinfo. Are there >> any reasons not to? [snip] > On the other hand, there's one argument against DocBook which you > didn't mention except in passing ("tools were already installed and > working"). (see below) > (Two more arguments to try if you're sufficiently frustrated: (1) find > a multideveloper project or two which switched to texinfo and has > written up a summary of why in retrospect it was a good decision, > and/or (2) convert 200 lines or so of text more or less cribbed from > the existing manual from DocBook to texinfo, with > foo-in-texinfo.texinfo, foo-in-docbook.xml, > foo.html-as-converted-by-texinfo, foo.html-as-converted-by-docbook, > and possibly some other output format you think would be convincing; > then send the resulting wouldnt-you-rather-work-with-texinfo.tar file > to the list.) I started doing the 200-line demo, got carried away and converted the=20 ffi chapter of the manual yesterday evening. The resulting pdf is at=20 <http://constantly.at/tmp/sbcl.pdf>; the sources are sbcl.texinfo and=20 ffi.texinfo in the same directory (which will be cleared in about a=20 month). I didn't put up html versions; to have a look, do `makeinfo=20 --html sbcl.texinfo' or `texi2html -split_chapter sbcl.texinfo'. Some comments: - I'll have to read up on texinfo-multiple-files-update; the inter-file=20= node references didn't seem to be updated correctly (within a single=20 file, C-u C-c C-u m updates all the inter-node references and creates=20 the node submenus -- very handy). - Likewise, I'll have to read up on texi2pdf -- I had hoped to show off=20= the automagic function index; `makeinfo --html' generates it, but=20 texi2pdf (and texinfo-the-program, for that matter) don't. - I'll try to overcome my angly-bracket phobia by cleaning up the=20 Docbook version of the ffi chapter a little bit and see if there's a=20 way to reduce the xml editing keystroke count. The offer for converting the manual into Texinfo still stands, but I=20 won't push it unless I solve the tool problems and get another attack=20 of <>-allergy. I'll work on the existing files a bit before attempting=20= to edit a huge chunk of manual again (more instant visual feedback will=20= make the learning easier, hopefully). Incremental changes are better=20 than wholesale rewriting most of the time; thanks for reminding me. Cheers, Rudi |
From: William H. N. <wil...@ai...> - 2004-03-25 14:58:26
|
I'm pretty much convinced. On Thu, Mar 25, 2004 at 08:02:30AM +0100, Rudi Schlatte wrote: > > On 24. Mär 2004, at 16:15, William Harold Newman wrote: > > >On Wed, Mar 24, 2004 at 02:20:05PM +0100, Rudi Schlatte wrote: > > > >>I'd like to volunteer translating the manual into texinfo. Are there > >>any reasons not to? > > [snip] > > >On the other hand, there's one argument against DocBook which you > >didn't mention except in passing ("tools were already installed and > >working"). > > (see below) > > >(Two more arguments to try if you're sufficiently frustrated: (1) find > >a multideveloper project or two which switched to texinfo and has > >written up a summary of why in retrospect it was a good decision, > >and/or (2) convert 200 lines or so of text more or less cribbed from > >the existing manual from DocBook to texinfo, with > >foo-in-texinfo.texinfo, foo-in-docbook.xml, > >foo.html-as-converted-by-texinfo, foo.html-as-converted-by-docbook, > >and possibly some other output format you think would be convincing; > >then send the resulting wouldnt-you-rather-work-with-texinfo.tar file > >to the list.) > > I started doing the 200-line demo, got carried away and converted the > ffi chapter of the manual yesterday evening. The resulting pdf is at > <http://constantly.at/tmp/sbcl.pdf>; the sources are sbcl.texinfo and > ffi.texinfo in the same directory (which will be cleared in about a > month). I didn't put up html versions; to have a look, do `makeinfo > --html sbcl.texinfo' or `texi2html -split_chapter sbcl.texinfo'. I looked briefly at your conversion, and it looks reasonable, which helps. I've also been impressed by the way that, so far, it seems that people with knowledge of both systems think that the switch would be somewhere between a reasonable idea and an actively good idea. I'd like to continue to solicit comments for a few days, since even people who don't read sbcl-devel obsessively every few hours can have something to contribute, but then if nothing else comes up and... > The offer for converting the manual into Texinfo still stands, but I > won't push it unless I solve the tool problems and get another attack > of <>-allergy. I'll work on the existing files a bit before attempting > to edit a huge chunk of manual again (more instant visual feedback will > make the learning easier, hopefully). Incremental changes are better > than wholesale rewriting most of the time; thanks for reminding me. ...you remain motivated to do the conversion, switching should be OK with me. -- William Harold Newman <wil...@ai...> However, since more people claim to have been abducted by aliens than to have ever seen the SGML standard, and since both encounters typically involve a feeling of "missing time", it's not surprising that the terminology of the SGML standard is not closely followed. -- <http://cken.chi.groogroo.com/rumor/groogroo.rumor> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: David L. <da...@li...> - 2004-03-25 15:35:08
|
Quoting William Harold Newman (wil...@ai...): > I'd like to continue to solicit comments for a few days, since even > people who don't read sbcl-devel obsessively every few hours can have > something to contribute, but then if nothing else comes up and... Well, when I tried to use Docbook I ended up using either TeX or Plain HTML instead... But one advantage of XML formats is that existing tools can handle them. There are XML parsers in Lisp. And there is XSL to transform the XML sources into anything else. (Though I am not aware of a full XSL engine in Lisp. :)) So even though I find the Docbook DTD to enforce very verbose and somewhat inflexible XML documents, I would not disregard XML as such because of that. Inventing your own DTD is always an option. For example, start with a subset of HTML and add elements like <defun>. Then write a simple XSL stylesheet to output HTML. (Or implement a renderer for your format in Closure and print to Postscript... :)) d. --=20 o To emphasize the highly professional nature of Nmap, all instances of "fucked up" in error message text has been changed to "b0rked". -- http://www.insecure.org/stf/Nmap-3.50-Release.html |
From: Rudi S. <ru...@co...> - 2004-03-25 20:27:39
Attachments:
PGP.sig
|
On 25. M=E4r 2004, at 16:35, David Lichteblau wrote: > But one advantage of XML formats is that existing tools can handle=20 > them. > There are XML parsers in Lisp. And there is XSL to transform the XML > sources into anything else. (Though I am not aware of a full XSL=20 > engine > in Lisp. :)) I confess I felt slightly bad replacing <variablename>, <function>,=20 <parameter> etc. with plain @code -- the transformation certainly was=20 lossy. But if xml is needed, makeinfo can do that. Anyway, it turns out that converting the rest of the manual took less=20 time than the ffi chapter that I picked as an easy first step to see if=20= it could be done. http://constantly.at/tmp/sbcl.pdf is the current=20 version, source files are in the same directory. The indices still=20 print only in the html version, though ... Cheers, Rudi |
From: William H. N. <wil...@ai...> - 2004-03-25 20:46:21
|
On Thu, Mar 25, 2004 at 09:27:27PM +0100, Rudi Schlatte wrote: > > On 25. Mär 2004, at 16:35, David Lichteblau wrote: > > >But one advantage of XML formats is that existing tools can handle > >them. > >There are XML parsers in Lisp. And there is XSL to transform the XML > >sources into anything else. (Though I am not aware of a full XSL > >engine > >in Lisp. :)) > > I confess I felt slightly bad replacing <variablename>, <function>, > <parameter> etc. with plain @code -- the transformation certainly was > lossy. But if xml is needed, makeinfo can do that. For what it's worth, some of the classification information which is being lost was wrong anyway.:-| For example, IIRC macros and special operators became <function>. -- William Harold Newman <wil...@ai...> "We have read your wonderful manuscript with boundless delight. But if we were to publish your illustrious paper, it would not be possible for us to keep face and publish any work of a lower standard. And, as it is unthinkable that in the next 1,000 years we shall ever again see its equal we are, to our regret, compelled to return your divine composition, and we beg you one thousand times, to overlook our short oversight and lowly heart." -- Zeborah in r.a.sf.w channelling Kai Lung PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Alexey D. <ade...@co...> - 2004-03-26 04:01:19
|
Rudi Schlatte <ru...@co...> writes: > Anyway, it turns out that converting the rest of the manual took less > time than the ffi chapter that I picked as an easy first step to see > if it could be done. http://constantly.at/tmp/sbcl.pdf is the current > version, source files are in the same directory. The node title "Compiler's Handling of Types" should probably be shortened to "Handling of Types": texi> * Unfortunately, you cannot use periods, commas, colons or texi> apostrophes within a node name; these confuse TeX or the Info texi> formatters. -- Regards, Alexey Dejneka "Alas, the spheres of truth are less transparent than those of illusion." -- L.E.J. Brouwer |
From: Rudi S. <ru...@co...> - 2004-03-26 06:25:14
Attachments:
PGP.sig
|
On 26. M=E4r 2004, at 05:07, Alexey Dejneka wrote: > The node title "Compiler's Handling of Types" should probably be > shortened to "Handling of Types": > Fixed, thanks. (New files at http://constantly.at/tmp/) Rudi |
From: Thomas F. B. <tfb@OCF.Berkeley.EDU> - 2004-03-26 00:39:08
|
William Harold Newman writes: > I'm pretty much convinced. ... > I'd like to continue to solicit comments for a few days, since even > people who don't read sbcl-devel obsessively every few hours can have > something to contribute, but then if nothing else comes up and... I'd advise going with Texinfo. For a while I worked at a company as the Guy Who Cleans Up Projects, which included writing a lot of documentation. I used both texinfo and docbook, and found texinfo waaaaay more usable. It worked perfectly well for multi-hundred page technical documents, so that shouldn't be a problem. |
From: Luke G. <lu...@bl...> - 2004-03-25 20:38:34
|
Rudi Schlatte <ru...@co...> writes: > I confess I felt slightly bad replacing <variablename>, <function>, > <parameter> etc. with plain @code -- the transformation certainly was > lossy. But if xml is needed, makeinfo can do that. You could preserve it with e.g. @macro variable{name} @code{name} @end macro And then @variable{foo} would mean @code{foo}. Possibly useful if you want to later make a variable-index. > Anyway, it turns out that converting the rest of the manual took less > time than the ffi chapter ... but maybe it's a bit late to suggest that :-) |
From: Paolo A. <am...@mc...> - 2004-03-24 16:11:10
|
Rudi Schlatte <ru...@co...> writes: > Now, texinfo has its weak spots (no support for graphics, the tag set See node Insertions/Images of the Texinfo manual. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film |
From: Nikodemus S. <tsi...@cc...> - 2004-03-24 17:55:34
|
Anecdotal experience, FWIW: I have only very limited experience with either texinfo or docbook, but texinfo I've found relatively painless to deal with, whereas with all my encounters with docbook have been quite unpleasant: essentially reducing the editing to whatever I could do without touching the tags. Cheers, -- Nikodemus |
From: Paolo A. <am...@mc...> - 2004-03-25 19:18:06
|
William Harold Newman <wil...@ai...> writes: > I'm pretty much convinced. [...] > I'd like to continue to solicit comments for a few days, since even > people who don't read sbcl-devel obsessively every few hours can have > something to contribute, but then if nothing else comes up and... Since you asked... The adoption of Texinfo may motivate me to contribute documentation to SBCL. In the past, I used Texinfo lightly, and it "felt comfortable". After Rudi's favorable comments in another list, I have started checking the manual in more depth, and I am now beginning to appreciate Texinfo even more. I have never used an SGML/XML-based formatting tool. More than once I decided to try this, but couldn't figure how to make the thing work and moved on. Also, I have never built the SBCL manual from source, mostly because I haven't figured which combination of SGML/XML tools and DocBook versions I need. Another point mentioned elsewhere is that Texinfo is well suited to documenting Lisp systems. Just my 2 pages... Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film |
From: Edi W. <ed...@ag...> - 2004-03-25 20:24:25
|
On Thu, 25 Mar 2004 18:25:00 +0100, Paolo Amoroso <am...@mc...> wrote: > I have never used an SGML/XML-based formatting tool. More than once > I decided to try this, but couldn't figure how to make the thing > work and moved on. > > Also, I have never built the SBCL manual from source, mostly because > I haven't figured which combination of SGML/XML tools and DocBook > versions I need. Let me second that: I *never* ever managed to build DocBook-based manuals from source - neither those of SBCL nor others - no matter on which system (FreeBSD and various Linux distros). Whatever abstract advantages DocBook might have - I as a simple Joe User can't use it... Cheers, Edi. |
From: Wolfgang J. <wje...@in...> - 2004-03-25 20:33:29
|
Rudi Schlatte <ru...@co...> writes: > I started doing the 200-line demo, got carried away and converted the > ffi chapter of the manual yesterday evening. The resulting pdf is at > <http://constantly.at/tmp/sbcl.pdf>; the sources are sbcl.texinfo and > ffi.texinfo in the same directory (which will be cleared in about a > month). I didn't put up html versions; to have a look, do `makeinfo > --html sbcl.texinfo' or `texi2html -split_chapter sbcl.texinfo'. If this is of any help, I have a texinfo version of a somewhat older version of the complete sbcl manual at http://members.inode.at/wjenkner/sbcl/sbcl-user.texi Its time-stamp is from Aug 25 2003. At that time the documentation was sgml but not xml based and I converted it it with osx -c /etc/sgml/sgml-docbook.cat -l /usr/share/sgml/xml/docbook/docbookx.dtd -xid -xlower -xno-expand-internal user-manual.sgml >user-manual.xml db2x_xsltproc -C /usr/share/sgml/xml/docbook/catalog.xml -s texi user-manual.xml >user-manual.txml Probably, I did a little bit of hand editing, too. Wolfgang |
From: Rudi S. <ru...@co...> - 2004-03-26 13:44:17
Attachments:
PGP.sig
|
On 26. M=E4r 2004, at 14:28, Christian Lynbech wrote: >>>>>> "Rudi" =3D=3D Rudi Schlatte <ru...@co...> writes: > > Rudi> I confess I felt slightly bad replacing <variablename>,=20 > <function>, > Rudi> <parameter> etc. with plain @code -- the transformation=20 > certainly was > Rudi> lossy. > > Isn't that a case where you could have used the definition commands, > such as "@deffn" for the description of a function, as described in > the texinfo manual in node: I used these; in fact that was the thing that convinced me to go with=20 texinfo: that for all the tag studliness of DocBook, function / macro /=20= etc. definitions were still marked up with <synopsis> tags followed by=20= <para>. What I meant were things like When <variable>hugo</variable> is bound to <literal>0</literal>,=20 <function>otto</function> frobnicates the ... (etc.). > And just to add something completely unrelated (well almost) I attach > some code I am currently using in a project. The idea is to ensure the > validity between a printed reference manual and the code simply by > documenting each function in lisp and then generate the etxinfo from > the lisp code by collecting the doc strings. This looks neat! What's the license status of the code? I think it=20 will be useful in the current MORE DOCUMENTATION effort in cirCLe. Rudi |
From: Christian L. <chr...@er...> - 2004-03-26 14:02:01
|
>>>>> "Rudi" =3D=3D Rudi Schlatte <ru...@co...> writes: Rudi> On 26. M=E4r 2004, at 14:28, Christian Lynbech wrote: >>>>>>> "Rudi" =3D=3D Rudi Schlatte <ru...@co...> writes: Rudi> What I meant were things like Rudi> When <variable>hugo</variable> is bound to <literal>0</literal>,=20 Rudi> <function>otto</function> frobnicates the ... (etc.). Hmm, I see. There is of course highlighting commands such as `var' and `command' but presumably it would be better to follow the previous advice of introducing a suitable set of additional commands mapping to @code. Rudi> This looks neat! What's the license status of the code? I think it= =20 Rudi> will be useful in the current MORE DOCUMENTATION effort in cirCLe. Share and enjoy. Let me know if you need something specific. It is a pretty small and crude hack and it has issues with long parameter lists (well the code hasn't but the result is not looking very pretty). I would suggest that for serious to rip out the idea and then start afresh with more thought put into the initial design. The good thing about doing something like this is that any documentation efforts benefits the manual and the online documentation equally well and they will always be in synch. =20=20=20=20=20=20=20=20 ------------------------+--------------------------------------------------= --- Christian Lynbech | christian #\@ defun #\. dk ------------------------+--------------------------------------------------= --- Hit the philistines three times over the head with the Elisp reference manu= al. - pe...@ha... (Michael A. Peton= ic) |