Stuart Rackham <[email protected]> writes: > On 14/09/10 04:55, Phillip Lord wrote: >> Essentially, I have a single macro in this which generates the main >> figure. In asciidoc terms, the macro definition converts something like >> >> >> rinc::reading.r[] >> >> into >> >> [source,R] >> ---- >> include::reading_split.r[] >> ---- >> (link:reading.r[Complete File])(link:reading.r.Rout[Rout]) >> >> which is then further expanded into, HTML. Obviously I want to avoid >> typing in the variations of the same filename three times, as this is a >> recipe for disaster. >> >> Is this at all possible with asciidoc? I couldn't work out whether this >> sort of recursive definition is possible. > > I can't think of a soution, did you get any further? Problem is that asciidoc > is not a recursive descent compiler, it's basically just a glorified pattern > match and replacer.
Stuart I've been thinking on this a bit. I did think of a couple of possible options. One seemed like a good idea, which was to write a style for asciidoc which did nothing -- just take an input asciidoc file and produce an output which was semantically identical. Transformations, such as Section ======= to == Section would be fine of course. Then it would be possible to add new macros, which expanded to more asciidoc syntax. It would then take two compliations to go asciidoc original -> asciidoc expanded -> final output. This might work, but there are two issues. First, it's not properly recursive, although you could achieve this with multiple passes. Second, the config files are hard to write because the templates for expansion look similar to the configuration file elements. The second option was to add a new class of element, which we might call expansions. These would operate like normal asciidoc macros, except, instead of being transformed into output text, would be translated into asciidoc which would then be injected back into the input reading stream in front of the current line. So once the expansion has happened, the results would then be parsed again, by the existing asciidoc mechanisms. This should recurse (potentially infiniately of course, but that is always going to be a possible issue with general recursion). I know that you have already wrapped the raw input reader, so it seems possible, although it might screw up line numbers for error reporting (since it would effectively make the input longer). The issue with the config files might well remain of course -- it may be hard to distinguish templates and new configuration elements. This is just a thought at the moment. The only other solutions I have are less ideal -- basically, generate my asciidoc using something like m4 (then we have two different expansion mechanisms), or use an editor based template mechanism, which has obvious issues with updating. Do either of these seem feasible to you? Phil -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
