Stuart Rackham <[email protected]> writes: > On 14/09/10 04:55, Phillip Lord wrote: >> 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.
I'm afraid not. The problem is that the system macros happen BEFORE any other templating. One solution would be to add a system macro that ran some python. So, you would define an interface in asciidoc which took attributes and the like. Then you would write a new python macro which had priority over all other (system) macros. In asciidoc you would then write something like python::foo.bar[args] asciidoc would import foo.bar, instantiate it, call a method in the interface, then do an "in-place" include into the doc, and carry on with the execution. Exactly how to interpret include statements would be a little difficult. In my example, they would need to be wrt to the main document. So, if I defined rinc -> python::phil.rinc[args] in x.conf, which returned an include statement, then in doc.adoc I had rinc::reading.r[] I'd need the include to happen wrt to doc.adoc. I may make an attempt at this at some point, but it's not going to be soon. 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.
