On 2 September 2012 12:48, Stuart Rackham <[email protected]> wrote:
> Ignore this from my last post it's wrong, opened my mouth before getting
> my brain into gear: "The current recursive id proposal
> would have to be modified to also include the callout list number from
> the parent and even then it would not work if the table included more
> than one callout list (asciidoc is spawned for each table cell not per
> table)."
Hi Stuart,
Ahh, I think this is right actually, the recursive_id method handles
*nested* callouts, not multiple invocations contributing to the same
calloutlist.
Something akin to what you describe would be needed for that.
But there is no simple way of knowing which calloutlist the callout is
contributing to since the callout comes before the callout list which
could be in the recursive invocation or in the parent.
So yes its all getting rather complicated.
Cheers
Lex
>
> Cheers, Stuart
>
>
> On 27/08/12 21:56, Wilhelm wrote:
>> Hi together,
>>
>> Am 26.08.2012 03:59, schrieb Stuart Rackham:
>>>
>> [...]
>>>
>>>>
>>>> "" 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.
>>
>> this looks very promising!
>> Do you see any chance to implement this in the next future ;-) ?
>>
>> Thanks,
>>
>> Wilhelm
>>
>>>
>>> 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.
>
--
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.
