* Require an eol after comments, so that an eol with content after it is
interpreted as a paragraph.
* 'eol >> eol' => 'eol >> *blank_p >> eol_p' so that lines containing
only a comment aren't interpreted as paragraph breaks.
* +eol after 'inside paragraphs' so that all the whitespace following
a paragraph is swallowed up. If it wasn't then it'd create lots of
empty paragraphs when there's a lot of whitespace.
[SVN r62700]
I'm not sure if the utf-16/32 checks are the right thing to do, but as
quickbook only supports utf-8 for now, they'll work okay. Hopefully if
it ever support other encodings this should be offloaded to an
appropriate library.
[SVN r59677]
Mostly administrative, but also disable xinclude test as it fails on some
platforms due to the different paths used by boost build, I'm not sure how to
fix it.
[SVN r58034]
{{{
[template foo 1]
[fool]
}}}
was generating `1[fool]` - the template would be expanded but then when it
didn't match the `]` it would fail and just get copied to the output. This
change checks for `]` before expanding the template. So it now generates
`[fool]` which is an improvement.
I'm not including a version switch as I see this as a plain bug fix - I can't
imagine this change ever being anything but beneficial.
[SVN r54816]
We're currently using the spirit escaped character parser. This is a
strict C parser and causes parse errors for code that we probably should
accept, such as any hexadecimal encoded characters with a value greater
than the maximum value of the current platform's 'char'. This is \x7F
on some platforms so it rejects '\x80' upwards. As well as rejecting
characters that might be valid, it also means that quickbook will act
differently on different platforms.
In python strings, '\xaaa' is equivalent to '\xaa' + 'a', but the spirit
parser interprets this as a character with value '0xaaa'. So we probably
should accept these.
I also think we should be liberal about what we accept. IMO it isn't our
job to enforce correct C++/python, just to create a reasonable
rendering of our input. So rather than write a parser which understands
the various types of escapes, I just wrote one that ignores any
character following a backslash.
Refs #2860.
[SVN r51949]
There was a failing test caused by a syntax error in a test. The
solution is probably to improve the syntax in a new version and issue a
warning in older versions.
[SVN r51801]
