--- [EMAIL PROTECTED] wrote: > Ralf, > > gclweb is only intended as an interim hack until we move to ANSI, > at which point I expect that the CWK algorithms will be used.
Hmm. Tim, looking at the TeX output from the noweb command it's a tad more involved than I originally expected. It should be possible to handle it, but in order to cover the general cases needed it will probably require some deeper digging into the why of various commands to check for corner case behavior specs. I have a couple quick orientation questions if you happen to know the answers: 1. The generated names such as NWcl*P-cop9-1 clearly are not assigned at random, but are based on the chunk name combined with some other strings. Is this merely for readability when assigning unique labels or does the structure of that name/label have a functional significance to the style file? 2. The list of chunks at the end of the file appears to be sorted in alphabetical order by the first non-numeric character in the chunk name - is that sort order necessary? The function of things like nwbegincode, nwendcode, nwbegindocs and nwenddocs is readily apparent, and for whatever reason each chunk and documentation region is assigned a number, bumped each time a new region is defined (all chunks have odd numbers, all doc regions even ones). The ones I'm not quite following yet are nwdocspar, nwixlogsorted, nwixd, are nwixu. One design question I'll ask now, because it will impact how work goes forward - should the initial scan of the buffer do all the work needed and place it in the structure, or should the extra steps only be taken if a separate scan function is called? I would not expect a drastic increase in scan time but most likely there would be some, if for no other reason than the extra assignment work to be done. Do we want to have a "pure" tangle that does only what is needed for the machine code, or should we have one scan function that records all info needed? > We should, however, debate the question of what FUNCTION we want > out of the pamphlets, as opposed to style and form. Do we want > hyperlinking, Absolutely. > biblographic references, My vote is a very definite yes, obviously. Better to have the key information in the pamphlet as opposed to buried in an obscure research paper someone would have to see $30 to see, and in that case we need to cite sources. Anyway, I would think references would be needed for algorithms in any case? > unit and regression testing, I'm sort of torn here. Certainly I think we need these tools and full documentation of the tests (why they've been selected, references, etc), but I'm not sure how they relate to pamphlets. I take it you are thinking of a specific chunk structure for unit tests? Hmm. > URL parsing, Doesn't the hyperref latex package already handle URLs? What functionality did you have in mind? > )compile compatibility, I certainly think this would be desirable. > hyperdoc/html processing, drag-and-drop processing, user examples, etc. Not sure what you mean by html processing - output of latex to html files? Reading html formatted commands/files? HTML output from LaTeX is a non-trivial problem and most solutions are imperfect. Not sure about other issues yet. > Since you've been pioneering the implementation of these ideas > using ALLPROSE perhaps you can put together an initial proposal > which we could maintain as "the pamphlet proposal". An initial > version would be an outline of the ALLPROSE current function. Agreed - such a document would be very useful. > Style and form questions are much harder to debate because we > have so many options. I feel we have to distinguish these from > their intended function so we don't get hung up in the details. Yes. Style ultimately should be configurable anyway - the thing to check there is that LaTeX packages used are compatible with each other. Cheers, CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
