From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2006-08-01 13:41:28
On 8/1/06, Julio M. Merino Vidal <jmmv84_at_[hidden]> wrote:
> On 8/1/06, John Maddock <john_at_[hidden]> wrote:
> > Joel de Guzman wrote:
> > >> So... I added a 'cinclude' tag (standing for code include) to
> > >> quickbook which, given a file, includes it in the documentation
> > >> marked up (and colored!) appropriately. The implementation is
> > >> attached. It can very well be flawed as it is basically a
> > >> copy&paste of other parts of the code, but so far seems to work.
> > >>
> > >> Any chance this -- or something similar -- can be integrated?
> > >
> > > Certainly. I might need to ask for some more cinclude related
> > > features. Are you willing to do some more coding? Please email
> > > me.
> > Just a thought, but would it be better to make [include ] a phrase level
> > element so it can include code or whatever, otherwise we'll end up with
> > [cinclude ] and [pyinclude ] and [terminal_include ] and...... etc.
> Note that cinclude stands for "code include", not "C include"; hence
> the pyinclude wouldn't exist ;-)
> Anyway, as Eric said it may be better to make [include] more
> intelligent. What about making it take two arguments, one specifying
> the file name and the other the format? E.g.
> [include somefile.xml xml]
> [include code.cpp c++]
> [include foo.qbk quickbook]
What about including only *part* of a file?
i.e. marking a file with with comments with something like
--- in file source.cpp ---
// quickbook:begin("section name")
// quickbook:end("section name")
[include source.cpp C++ "section name"]
would include only that part of the file.
Useful if you want to pull for example only a function prototype, or a
-- Giovanni P. Deretta