templates, macros and spaces

[John Maddock]

I've been experimenting with templates and macros over lunch (well what else
does a guy do?) and it's not really working as required just yet, given:

[def __alpha '''α''']
[template super(text) '''<superscript>'''text'''</superscript>''' ]
[template pow(a, b) a'''<superscript>'''b'''</superscript>''' ]

Then:

x super(2)

Puts a space between the x and the superscript-2

x[/ ]super(2)

So does this.

pow(x, 2)

And this :-(

pow(__alpha, 2)

Macro alpha expands OK, but that space is still there...

'''x<superscript>2</superscript>'''

Is obviously OK, but:

[template pow(a, b) '''a<superscript>b</superscript>''' ]

pow(x,2)

prints a^b not x^2 :-(

It's not just super/sub scripts either: try to define a macro or template to
expand out unit's of epsilon and the space gets even more obvious, there's
no way at present to write out 2eps using the right symbol for "eps" except
by doing the whole thing in XML.  Since the digit obviously varies from
usage to usage, that's not nice!  Try and write out an equation
"2-alpha-beta-squared" and you'd pretty rapidly give up, before it gets any
more complex.

Some of this appears to be due to XML escapes always being pretty-printed on
a new line, so

pow(x, 2) comes out as:

x
<superscript>
2
</superscript>

Which is where at least some of the spaces come from.

So.... I'm hoping that this can be solved by changing the pretty-printing
code, but I have suspicions that the problems may run deeper.

Hoping to be proved wrong,
John.



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[David Abrahams]

"John Maddock" <john@...> writes:

> So.... I'm hoping that this can be solved by changing the pretty-printing
> code, but I have suspicions that the problems may run deeper.

In ReST they have a "breaking non-space."  That is, if you
backslash-escape a space character, you get something that can
separate tokens without generating any space in the output:

  x\ super(2)

In quickbook maybe that should be:

  x[]super(2)

Although I think I might prefer:

  x!super(2)

An exclamation point with no whitespace on either side is sufficiently
rare, I think.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[Andy Little]

"David Abrahams" wrote

> "John Maddock" wrote
>
>> So.... I'm hoping that this can be solved by changing the pretty-printing
>> code, but I have suspicions that the problems may run deeper.
>
> In ReST they have a "breaking non-space."  That is, if you
> backslash-escape a space character, you get something that can
> separate tokens without generating any space in the output:
>
>  x\ super(2)
>
> In quickbook maybe that should be:
>
>  x[]super(2)
>
> Although I think I might prefer:
>
>  x!super(2)
>
> An exclamation point with no whitespace on either side is sufficiently
> rare, I think.

How about a function that performs concatenation, say 'cat'

 [cat lhs rhs]

(using alt syntax)

regards
Andy Little





_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[Joel de Guzman-2]

John Maddock wrote:
> I've been experimenting with templates and macros over lunch (well what else
> does a guy do?)

Haha!

> and it's not really working as required just yet, given:
>
> [def __alpha '''α''']
> [template super(text) '''<superscript>'''text'''</superscript>''' ]
> [template pow(a, b) a'''<superscript>'''b'''</superscript>''' ]
>
> Then:
>
> x super(2)
>
> Puts a space between the x and the superscript-2

I see. And there is no way to juxtapose x and super
without the space. This, I guess, is another case for
the new proposed syntax:

     x[super 2]

[...]

> It's not just super/sub scripts either: try to define a macro or template to
> expand out unit's of epsilon and the space gets even more obvious, there's
> no way at present to write out 2eps using the right symbol for "eps" except
> by doing the whole thing in XML.  Since the digit obviously varies from
> usage to usage, that's not nice!  Try and write out an equation
> "2-alpha-beta-squared" and you'd pretty rapidly give up, before it gets any
> more complex.
>
> Some of this appears to be due to XML escapes always being pretty-printed on
> a new line, so
>
> pow(x, 2) comes out as:
>
> x
> <superscript>
> 2
> </superscript>
>
> Which is where at least some of the spaces come from.
>
> So.... I'm hoping that this can be solved by changing the pretty-printing
> code, but I have suspicions that the problems may run deeper.

Quite probably. I can take a look sometime tonight and see how it
goes. Thanks for your experiments! That will help me get things
straightened up. I'm sure we'll find a good nice solution.

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[John Maddock]

David Abrahams wrote:

> "John Maddock" <john@...> writes:
>
>> So.... I'm hoping that this can be solved by changing the
>> pretty-printing code, but I have suspicions that the problems may
>> run deeper.
>
> In ReST they have a "breaking non-space."  That is, if you
> backslash-escape a space character, you get something that can
> separate tokens without generating any space in the output:
>
>  x\ super(2)
>
> In quickbook maybe that should be:
>
>  x[]super(2)
>
> Although I think I might prefer:
>
>  x!super(2)
>
> An exclamation point with no whitespace on either side is sufficiently
> rare, I think.

That would do it, but note that we already have a poor-man's version of this
using an empty comment:

x[/]super(2)

But you still get the extra whitespace :-(

Even this:

x'''<superscript>2</superscript>'''

has extra whitespace inserted!

John.



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[Andy Little]

"David Abrahams" wrote

> John Maddock wrote
>
>> So.... I'm hoping that this can be solved by changing the pretty-printing
>> code, but I have suspicions that the problems may run deeper.
>
> In ReST they have a "breaking non-space."  That is, if you
> backslash-escape a space character, you get something that can
> separate tokens without generating any space in the output:
>
>  x\ super(2)
>
> In quickbook maybe that should be:
>
>  x[]super(2)
>
> Although I think I might prefer:
>
>  x!super(2)
>
> An exclamation point with no whitespace on either side is sufficiently
> rare, I think.

How about a function that performs concatenation,:

 [cat lhs rhs]

It may be more legible. The use of x!super(2) is somewhat cryptic IMO.

regards
Andy Little



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[Joel de Guzman-2]

John Maddock wrote:

> David Abrahams wrote:
>> "John Maddock" <john@...> writes:
>>
>>> So.... I'm hoping that this can be solved by changing the
>>> pretty-printing code, but I have suspicions that the problems may
>>> run deeper.
>> In ReST they have a "breaking non-space."  That is, if you
>> backslash-escape a space character, you get something that can
>> separate tokens without generating any space in the output:
>>
>>  x\ super(2)
>>
>> In quickbook maybe that should be:
>>
>>  x[]super(2)
>>
>> Although I think I might prefer:
>>
>>  x!super(2)
>>
>> An exclamation point with no whitespace on either side is sufficiently
>> rare, I think.
>
> That would do it, but note that we already have a poor-man's version of this
> using an empty comment:
>
> x[/]super(2)

Good idea! It should definitely work. The reason why it is not working
is unrelated, but I think I know why.

> But you still get the extra whitespace :-(

Ok, here's what I think:

My proposed syntax:

    x[super 2]

does not have this problem. You do not need to add a space between
x and the template /super/. It is also sufficiently unambiguous.
It does not look like a common function call so you do not have
to resort to some naming convention, like double-underscores.

If there are no objections, I'd like to switch to this syntax to
templates. Applying it to macros will break existing qbk files,
which I do not want to do. So, I'll just let them be and get
them deprecated. That means, I'd like templates to totally replace
macros.

So, going back to John's experiment, I'd like the final qbk code
to be:

     [template alpha[] '''α''']
     [template super[text] '''<superscript>'''[text]'''</superscript>''']
     [template pow[a, b] [a]'''<superscript>'''[b]'''</superscript>''' ]

Notice [text], [a] and [b] are bracketed. They are essentially
templates that exist only in the duration of the template body
(that is their scope). Notice too that alpha[] is a nullary
template.

Then...

     x[super 2]
     [pow[x][2]]
     [pow[alpha][2]]

I am confident I can get this to work. Comments? Objections?

> Even this:
>
> x'''<superscript>2</superscript>'''
>
> has extra whitespace inserted!

Which is clearly wrong. I'll investigate some more. I think it has to do
with tagging escaped HTML and placing them in separate line.

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[João Abecasis-2]

Joel de Guzman wrote:

> So, going back to John's experiment, I'd like the final qbk code
> to be:
>
>      [template alpha[] '''α''']
>      [template super[text] '''<superscript>'''[text]'''</superscript>''']
>      [template pow[a, b] [a]'''<superscript>'''[b]'''</superscript>''' ]
>
> Notice [text], [a] and [b] are bracketed. They are essentially
> templates that exist only in the duration of the template body
> (that is their scope). Notice too that alpha[] is a nullary
> template.

I'd make the nullary brackets optional. They may be needed to avoid
ambiguity with a bracketed expression at the beginning of the
definition, but in other situations they look superfluous.

Another thing we can consider is dropping the comma. I think this looks
more quickbooky:

    [template pow[a b] [a]'''<superscript>'''[b]'''</superscript>''' ]

Best regards,


João


_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[John Maddock]

Joel de Guzman wrote:

> My proposed syntax:
>
>    x[super 2]
>
> does not have this problem. You do not need to add a space between
> x and the template /super/. It is also sufficiently unambiguous.
> It does not look like a common function call so you do not have
> to resort to some naming convention, like double-underscores.
>
> If there are no objections, I'd like to switch to this syntax to
> templates. Applying it to macros will break existing qbk files,
> which I do not want to do. So, I'll just let them be and get
> them deprecated. That means, I'd like templates to totally replace
> macros.
>
> So, going back to John's experiment, I'd like the final qbk code
> to be:
>
>     [template alpha[] '''α''']
>     [template super[text]
>     '''<superscript>'''[text]'''</superscript>'''] [template pow[a,
> b] [a]'''<superscript>'''[b]'''</superscript>''' ]
>
> Notice [text], [a] and [b] are bracketed. They are essentially
> templates that exist only in the duration of the template body
> (that is their scope). Notice too that alpha[] is a nullary
> template.
>
> Then...
>
>     x[super 2]
>     [pow[x][2]]
>     [pow[alpha][2]]
>
> I am confident I can get this to work. Comments? Objections?

I quite like that, certainly it makes univariate macros look just like
quickbook built-ins, I'm not so sure about the multivariate syntax, but I
don't have strong objections.

Hmmm, currently builtins with multiple arguments have them separated by
whitespace, could we preserve this behaviour and fall back to putting []
around arguments only if the argument contains whitespace?

So:

[pow x 2]

does what you would expect.

[pow x a + b]

places "a + b" as the superscript, it's the same as:

[pow x [a + b]]

while

[pow [x - y] [a + b]]

separates it's arguments as you'd expect (a bad example though in the math
sense).

This follows the existing rules for builtin's I think, with the extension
that arguments can contain deliberate whitespace if you put [] around the
arguments.  And of course [] would be an empty-string-argument.

How does that sound?

John.



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[Joel de Guzman-2]

John Maddock wrote:

> Joel de Guzman wrote:
>
>> My proposed syntax:
>>
>>    x[super 2]
>>
>> does not have this problem. You do not need to add a space between
>> x and the template /super/. It is also sufficiently unambiguous.
>> It does not look like a common function call so you do not have
>> to resort to some naming convention, like double-underscores.
>>
>> If there are no objections, I'd like to switch to this syntax to
>> templates. Applying it to macros will break existing qbk files,
>> which I do not want to do. So, I'll just let them be and get
>> them deprecated. That means, I'd like templates to totally replace
>> macros.
>>
>> So, going back to John's experiment, I'd like the final qbk code
>> to be:
>>
>>     [template alpha[] '''α''']
>>     [template super[text]
>>     '''<superscript>'''[text]'''</superscript>'''] [template pow[a,
>> b] [a]'''<superscript>'''[b]'''</superscript>''' ]
>>
>> Notice [text], [a] and [b] are bracketed. They are essentially
>> templates that exist only in the duration of the template body
>> (that is their scope). Notice too that alpha[] is a nullary
>> template.
>>
>> Then...
>>
>>     x[super 2]
>>     [pow[x][2]]
>>     [pow[alpha][2]]
>>
>> I am confident I can get this to work. Comments? Objections?
>
> I quite like that, certainly it makes univariate macros look just like
> quickbook built-ins, I'm not so sure about the multivariate syntax, but I
> don't have strong objections.
>
> Hmmm, currently builtins with multiple arguments have them separated by
> whitespace, could we preserve this behaviour and fall back to putting []
> around arguments only if the argument contains whitespace?

Indeed. At first I wondered what those built-ins are. So, I noticed
builtins such as [link section.anchor Link text]. With those, the
general syntax is:

    [markup no-space space allowed here]

The first argument may not contain any space while the second argument
may. I guess this is a special case worth considering, otherwise, we
cannot emulate the built-ins with templates. Note that this is a
special case for binary arguments only.

> So:
>
> [pow x 2]
>
> does what you would expect.

Ok.

> [pow x a + b]
>
> places "a + b" as the superscript, it's the same as:
>
> [pow x [a + b]]

Ok.

> while
>
> [pow [x - y] [a + b]]
>
> separates it's arguments as you'd expect (a bad example though in the math
> sense).

I see.

> This follows the existing rules for builtin's I think, with the extension
> that arguments can contain deliberate whitespace if you put [] around the
> arguments.  And of course [] would be an empty-string-argument.
>
> How does that sound?

I think that sounds logical and implementable. Thanks for noting that.
Your comments are invaluable!

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[Joel de Guzman-2]

João Abecasis wrote:

> Joel de Guzman wrote:
>> So, going back to John's experiment, I'd like the final qbk code
>> to be:
>>
>>      [template alpha[] '''α''']
>>      [template super[text] '''<superscript>'''[text]'''</superscript>''']
>>      [template pow[a, b] [a]'''<superscript>'''[b]'''</superscript>''' ]
>>
>> Notice [text], [a] and [b] are bracketed. They are essentially
>> templates that exist only in the duration of the template body
>> (that is their scope). Notice too that alpha[] is a nullary
>> template.

Disagree. They are needed. Otherwise, we'll end up with obscure
naming conventions like __a__ again. Take note that the template
body is just about any quickbook phrase/block. a, in the pow
example above is actually a template that exists in the duration
of the template body of pow. I'd like template invocations to
always be explicit: bracket them; hence [a].

> I'd make the nullary brackets optional. They may be needed to avoid
> ambiguity with a bracketed expression at the beginning of the
> definition, but in other situations they look superfluous.
>
> Another thing we can consider is dropping the comma. I think this looks
> more quickbooky:
>
>     [template pow[a b] [a]'''<superscript>'''[b]'''</superscript>''' ]

Agreed. That's doable. I'm also considering allowing certain punctuation
characters as template identifiers. I think it is safe if the
invocation is always explicit. That would allow us to rewrite many
of the builtins, such as [*bold], as templates. So, right now, I
notice that a template identifier is either:

* a single char punctuation (e.g. '*', '_', '^', etc.)
* a C-style identifier

Having that, we can extensively simplify the qbk code to around 10%
its original size. If we add variadic args to templates, then we can
go further and have the tables and the doc-info prefix as templates.
But I guess that's a battle for another day :)

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[David Abrahams]

Joel de Guzman <joel@...> writes:



> João Abecasis wrote:

>> Joel de Guzman wrote:

>>> So, going back to John's experiment, I'd like the final qbk code

>>> to be:

>>>

>>>      [template alpha[] '''α''']

>>>      [template super[text] '''<superscript>'''[text]'''</superscript>''']

>>>      [template pow[a, b] [a]'''<superscript>'''[b]'''</superscript>''' ]

>>>

>>> Notice [text], [a] and [b] are bracketed. They are essentially

>>> templates that exist only in the duration of the template body

>>> (that is their scope). Notice too that alpha[] is a nullary

>>> template.

>

> Disagree. They are needed. Otherwise, we'll end up with obscure

> naming conventions like __a__ again. Take note that the template

> body is just about any quickbook phrase/block. a, in the pow

> example above is actually a template that exists in the duration

> of the template body of pow. I'd like template invocations to

> always be explicit: bracket them; hence [a].



Are you the least bit worried about clashes with, e.g.



    int[3]



and



    x[0]



??



>> I'd make the nullary brackets optional. They may be needed to avoid

>> ambiguity with a bracketed expression at the beginning of the

>> definition, but in other situations they look superfluous.

>>

>> Another thing we can consider is dropping the comma. I think this looks

>> more quickbooky:

>>

>>     [template pow[a b] [a]'''<superscript>'''[b]'''</superscript>''' ]

>

> Agreed. That's doable. I'm also considering allowing certain punctuation

> characters as template identifiers. I think it is safe if the

> invocation is always explicit. That would allow us to rewrite many

> of the builtins, such as [*bold], as templates. So, right now, I

> notice that a template identifier is either:

>

> * a single char punctuation (e.g. '*', '_', '^', etc.)

> * a C-style identifier

>

> Having that, we can extensively simplify the qbk code to around 10%

> its original size. If we add variadic args to templates, then we can

> go further and have the tables and the doc-info prefix as templates.

> But I guess that's a battle for another day :)



I really like the direction of driving more functionality into the

"library."



--

Dave Abrahams

Boost Consulting

www.boost-consulting.com




_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[Joel de Guzman-2]

David Abrahams wrote:

Hi Dave,

It's interesting to note that some of your posts have this
double newline thing. Anyway...

> Are you the least bit worried about clashes with, e.g.
>
>     int[3]
>
> and
>
>     x[0]
>
> ??

Well, no.

1) 3 and 0 are not legal template identifiers anyway.
    Perhaps:

    int[x] or z[y] are better examples. But then...

2) If x or y are not in the template symbol table, then those
    will not be regarded as templates.

3) int[x] and z[y] should be written as `int[x]` and `z[y]`

4) You are probably playing with quickbook if you use the brackets
    as-is since those are the primary quickbook markup characters.
    Quickbook tries to be forgiving if you do, but you better
    know what you are doing.

> I really like the direction of driving more functionality into the
>
> "library."

Glad to hear. Yeah, me too!

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[Joel de Guzman-2]

John Maddock wrote:

Ok, fixed. see below:

> [def __alpha '''α''']
> [template super(text) '''<superscript>'''text'''</superscript>''' ]
> [template pow(a, b) a'''<superscript>'''b'''</superscript>''' ]

 > pow(x, 2)

Fixed.

 > pow(__alpha, 2)

Fixed.

 > x super(2)

Expected.

> x[/ ]super(2)

Fixed but note how I wrote the template:

[template pow(a, b)a'''<superscript>'''b'''</superscript>''']

Notice no space in between b) and a. That space is significant.
Note too that the space in the comment is not needed:

x[/]super(2)

Okidoki. That's all for now. Next stop will be the new template syntax.
And hopefully, moving the bulk of quickbook to a library.

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[Joel de Guzman-2]

Joel de Guzman wrote:

> Okidoki. That's all for now. Next stop will be the new template syntax.
> And hopefully, moving the bulk of quickbook to a library.

Ok, now we have templates in the syntax that we discussed.

Examples (from John):

     [template alpha '''α''']
     [template pow[a b] a'''<superscript>'''b'''</superscript>''' ]
     [template super[text]'''<superscript>'''text'''</superscript>''' ]

     [pow x 2]

     [pow [alpha] 2]

     x[super 2]

There's a minor change though for multiple args. I used the double
dot as the separator "..". The code above can also be written as:

     [pow x..2]

We once considered the syntax:

     [pow [x][2]]

but I realized that it is ambiguous because the arguments passed can
be just about any quickbook phrase. For example:

     [my_template [$image.jpg]..[^boldified]]

This is not possible using brackets as separators.

The logic behind the simplified (no separator) syntax like:

     [pow x 2]

is actually quite simple: First, "x 2" is treated as just
one argument. If the template expects more arguments, then
it tries to break the argument at the first space found.

(I realized this can apply to arbitrary N-ary arguments.
I'll adjust the code later to accommodate N arguments using
that logic)

Committed to CVS. Have fun!

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[Joel de Guzman-2]

Hi Y'all,

I should be in vacation right now, but I can't resist some
coding for fun. So, I think we now have the templates in its
final form. See the docs here:

http://spirit.sourceforge.net/dl_docs/quickbook_doc/doc/html/quickbook/syntax/block.html#quickbook.syntax.block.templates

(sorry tinyurl seems to be down ATM)

Now, I'm on to providing template namespaces. My plan is
for each qbk file to have its own template namespace.
Access to each file's template namespace will be:

     [doc_id.template_id arg1 arg2...argN]

You may also wish to import all templates from an included
qbk file:

     [import doc_id]

Have fun!

Cheers,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[João Abecasis-2]

Joel de Guzman wrote:
> You may also wish to import all templates from an included
> qbk file:
>
>      [import doc_id]

I think it'd be nice to be able to export things into the global
namespace so we won't need to put


     [import std]

everywhere.

> Have fun!

Enjoy your vacation!


João


_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[Joel de Guzman-2]

João Abecasis wrote:

> Joel de Guzman wrote:
>> You may also wish to import all templates from an included
>> qbk file:
>>
>>      [import doc_id]
>
> I think it'd be nice to be able to export things into the global
> namespace so we won't need to put
>
>      [import std]
>
> everywhere.

Definitely. In fact, it's the only way to go for backward
compatibility. Old quickbook docs should still work as-is.
I suggest a "std.qbk" file in a quickbook tools "include"
folder. This file is always automatically included and
imported.

>> Have fun!
>
> Enjoy your vacation!

T'was a short one. I'm back.

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[dan marsden]

With the old pre-templates quickbook, we had a feature for deducing the correct heading level with:
[heading Stuff] equivalent to [hN Stuff] where N is the depth of nested [section]s.

So my question is, with the new scheme using templates, would we be able access depth (or even manipulate other arbitrary variables) so that something such as the heading directive could be implemented using the template mechanism?

Or is this already possible with the template mechanism in some other way?

Cheers
Dan




_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs

[Joel de Guzman-2]

dan marsden wrote:
> With the old pre-templates quickbook, we had a feature for deducing
> the correct heading level with: [heading Stuff] equivalent to [hN
> Stuff] where N is the depth of nested [section]s.
>
> So my question is, with the new scheme using templates, would we be
> able access depth (or even manipulate other arbitrary variables) so
> that something such as the heading directive could be implemented
> using the template mechanism?

Short answer: no.

> Or is this already possible with the template mechanism in some other
> way?

That's a perfect job for Python! :) I guess we should provide a
boost python wrapper support for accessing the parser state info.
This is Dave's wish list and I intend to pursue it along these
lines. Python will have access to the "collectors", the (soon
to be) "code stacks", filenames, symbol tables, etc. Then, in
Quickbook, we can pass info to and from Python.

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net



_______________________________________________
Boost-docs mailing list
Boost-docs@...
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs