On 25/08/12 23:19, Lex Trotman wrote:
[...]
A counter would be tricky as it needs to handle
multiple recursive dives e.g
top level initializes id to 1,
child increments id to 2,
back to parent (with id=1),
next child increments id to 2, <-- should be 3
Hi Stuart,
I didn't explain my idea clearly enough, sorry (and I'm not in front
of a machine where I could just make a patch). Let me try again.
The idea is that callout ids are co{recursive_id}_n_m where n is of
course the callout list number and m the member of that list (as now).
Top level asciidoc is called without the user setting {recursive_id}
and it should default to ""
A recursive asciidoc is called with -a recursive_id="{recursive_id}_r"
where r is the count of how many recursive calls *this* asciidoc has
made.
Thats all there is to it, no tricky passing stuff up/sideways or anything else.
So for a three level two wide tree of calls {recursive_id} takes the
values (listed depth first):
"" for the top level
"_1" for the first child
"_1_1" for the first grandchild via child1
"_1_2" for the second grandchild via child1
"_2" for the second child
"_2_1" for the first grandchild via child2
"_2_2" for the second grandchild via child2
Ah, that makes sense, and it's much better than my PID idea
(aside the fact that, as you explained,l it wouldn't work anyway)
which is non-deterministic in that the exact same source
document would generate different outputs each time it
was compiled.
Cheers, Stuart
This scheme does not distinguish siblings.
The child would have to have to have some way to pass
the id back to the parent, either that or:
- a globally accessible id thats incremented when
asciidoc starts execution
Then I can't build my documentation with make -j (ie multiple parallel
jobs) unless the "global" is very tricky and concurrent safe :(
- or some sort or UUID generator
Possible but UUIDs tend to be big and messy things.
- or the process PID (os.getpid())
Not all systems guarantee *not* to re-use PIDs after the processes
that have them exit, although Linux just keeps incrementing the PID.
But POSIX only requires that a fork return a PID that is not in use at
the moment, so successive children may have the same PID, been there,
fallen in that hole :)
Cheers
Lex
The process PID would be easiest (a new intrisic {pid} attribute).
Cheers, Stuart
Cheers
Lex
Cheers
Lex
Cheers
Lex
Cheers, Stuart
test case follows:
[cols="<95%asciidoc,>.<5%",frame="none",grid="none",options="header",role="code"]
|====
|Überschrift |
|["source","java",role="codeintable"]
----
public void add(Comparable<T> value) { // <1>
}
----
<1> Bla
| randomtext
|====
[cols="<95%asciidoc,>.<5%",frame="none",grid="none",options="header",role="code"]
|====
|Überschrift |
|["source","java",role="codeintable"]
----
public void add(Comparable<T> value) { // <1>
}
----
<1> Bla
| randomtext
|====
--
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.
--
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.
--
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.
--
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.
