On 20 November 2012 10:40, Lex Trotman <[email protected]> wrote:
>
>
>
> On 20 November 2012 02:10, Wilhelm <[email protected]> wrote:
>>
>> Hi all,
>>
>> very frequently I have to write something like the following:
>>
>> .[codetitle]#{srccaption}# 
>> link:{src}/{chap}/{subchap}/coffee05/Coffee.java[[codelink]+coffee05/Coffee.java+]
>> ifdef::backend-docbook[]
>> ["source","java",args="role=\"code\""]
>> endif::[]
>> ifndef::backend-docbook[]
>> ["source","java"]
>> endif::[]
>> ----
>> sys::[{ex} Fillable {src}/{chap}/{subchap}/coffee05/Coffee.java]
>> ----
>> <1> The interface
>>
>>
>> where {ex} is set to my source-code extractor tool, "Fillable" is the 
>> snippet name to be extracted and the other document attributes are set 
>> accordingly.
>>
>> I wonder if it is possible to write a macro to replace all the stuff from 
>> above with *one* call, e.g.
>
>
> Hi Wilhelm,
>
> It is, but....
>
> Asciidoc "macros" are output substitution macros, not input substitution 
> macros that many other languages have.  This means that you have to generate 
> all the backend output you need yourself, so complex things are much harder, 
> you can't run it back through asciidoc without going recursive (but that can 
> be done, see how asciidoc table styles are implemented, it may be that is 
> your solution).
>
> I guess Asciidoc doesn't do input macro substitution since, in the Unix 
> environment where it started, there are already several ways of doing input 
> substitution, one of which you have found.  But they do cause the line number 
> problem.  A nice-to-have would be for Asciidoc to accept line/column 
> specifications as C compilers do to re-align input to the original source 
> file/line/column at the end of a substitution.

Hi Wilhelm,

A while after pressing return (isn't it always the case) it occurred
to me that there may be a way of avoiding the line number problem.
Instead of writing multiple lines to the Asciidoc source file, which
messes up the line numbers, you could write the multiple lines to a
small file and just write an include macro in the Asciidoc source.
Since this include macro is the same size as your
"source::Coffee.java[Fillable]" it should not mess up the line
numbers.

In all probability the overhead won't be too much, especially if you
put the little include files on a memory file system (/tmp on many
modern distros).

Cheers
Lex


>
>
> Just an aside, some time ago I was creating a plugin to extract stuff and put 
> it in source blocks as you are doing.  In the end I moved the whole thing to 
> a pre-processor that extracted all the marked code snippets once and then 
> made one pass through the asciidoc file to plug them in, much simpler, and of 
> course it also plugged in the boilerplate, and muuuuuuuch faster since it 
> searches the input once only.  But that may not matter if you are only doing 
> a few snippet insertions.
>
>
> Cheers
> Lex
>>
>>
>> source::Coffee.java[Fillable]
>> <1> The interface
>>
>> Any hints are welcome!
>>
>> Actually I'm doing some preprocessing of the asciidoc-file with an awk-based 
>> tool: this tool replaces the "pseudo" block-macro call
>>
>> source::Coffee.java[Fillable]
>>
>> with the stuff above. It works quite well but has the disadvantage that the 
>> line numbers in error/warnings of asciidoc are displaced because more lines 
>> are generated.
>>
>> --
>> Wilhelm
>>
>> --
>> 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.

Reply via email to