On 01/12/10 19:38, Lex Trotman wrote:
On 1 December 2010 10:49, Henrik<[email protected]> wrote:
Hi Lex,
there is already a provision for this in latest AsciiDoc. Refer to
manual chapter 24.1. Setting configuration entries.
You should be able to embed the configuration setting in the header
like:
:xref2-inlinemacro:<a href="#{1}">{2={1}}</a>
Cheers
Henrik
Thanks Henrik, I only looked at section 22 :-S
Thats my option 3 done, now it only needs option 1 for large changes
that are a bit intrusive in the header.
Something like:
:conf-files: filename[|filename]...
These conf files would behave just like conf files specified on the command-line
and would be loaded immediately prior.
I've committed a patch but it needs testing:
http://code.google.com/p/asciidoc/source/detail?r=e3919f2ce35a83fd199758e4f25544792115e511
Cheers, Stuart
Note that having to specify --conf-file on the command line means that
build scripts have to explicitly name each file and of course new
files get forgotten.
It is better to be able to have a single make recipe for all .txt
files in the directory
Cheers
Lex
On Nov 30, 10:26 am, Lex Trotman<[email protected]> wrote:
Hi Stuart,
I am occasionally running into the problem of one file in a group that
needs slightly different configuration.
For example, one file should not put XHTML autogenerated links in []
so it has an asciidoc.conf containing:
[xref2-inlinemacro]
<a href="#{1}">{2={1}}</a>
Now the file has to live in its own directory or the asciidoc,conf
will apply to all the files in the directory.
Instead could asciidoc have a method of handling file-specific
configuration. My thoughts were:
1. the source file can specify a config-files attribute in its header
to identify specific config files.
2. for some_file.txt look for some_file.conf in the same directory (-e
uses ONLY infile.conf IIUC, thats not what I mean)
3. allow embedded configuration, maybe in a structured comment, eg for the above
///////////////////////////
//configuration:
[xref2-inlinemacro]
<a href="#{1}">{2={1}}</a>
/////////////////////////
The advantage of 3 is that then only one file needs to be shipped
around so the config can't get lost. The advantage of 1. and 2. is
that large config changes don't intrude on the source.
The advantage of 1. is that several source files can share the same
config without all having to do so.
So I'd prefer 1& 3 (greedy, moi?? :-)
A couple of notes regarding loading of config files section of the
user guide (section 22.11) the line:
<backend>.conf and<backend>-<doctype>.conf from location 4. 2,3.
probably should not have the 2,3 on the end.
The Where clause defines<infile> but its not used anywhere.
Cheers
Lex
--
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.
