Joel de Guzman wrote:
Reece Dunn wrote:
some great stuff which I failed to read before responding to Joel, which
might have saved me some trouble......
With the above syntaxes, the symbol/regex definitions are bound to
the colour/format schemes. It may be useful to separate these out,
allowing:
[highlighting
[keywords red bold]
[comments "C++" teal]
[comments "C" cyan]
[preprocessor bold olive]
]
These are just ideas. I am not sure how feasible they may be.
Very feasible, IMHO.
Wonderful idea! It all boils down to:
1) Having a qbk include mechanism.
Yes!
2) Providing a command line switch to specify the search directory
for includes
Yes!
4) Having a default.qbk automatically included.
<<This is important for backward compatibility. The
default.qbk contains the current highlighting schemes>>
Yes! Plus this allows us to easily add "built-in" support for new
types. I would suggest something similar Boost Build, such as
"bootstrap.qbk" for global setup and a "user.qbk" allowing additional
site-specific tweaks without having to modify (and then merge at the
next release) "bootstrap.qbk".
I think this is all very reaonable.
I'm not sure however if its a good idea to go as far as
specifying the colors for each. That's the job of the CSS
file. Do you want the ability to rewrite the CSS file too?
Nah, that's too much, I think.
Actually, this is the only thing I didn't like, and I REALLY don't like
it (but this in no way detracts from being very impressed with Reece's
suggestions taken as a whole!) because it IMHO corrupts the interface.
QuickBook provides a user-friendly way to express documentation with
context appropriate to Boost Libraries. It's elegance comes from what
it omits as well as what it permits - useful patterns require negative
space. QuickBook can identify relevant context within our problem
domain (like: here's a keyword) and annotate the BoostBook xml output
with that context. The BoostBook system (which includes the CSS files)
dictates how that context should be displayed (like: show keywords in
green), and may do so differently for different output targets. Trying
to do that in QuickBook source violates the separation of concerns that
makes consistency between projects possible while allowing variation of
and refinement to the BoostBook target formats (html, PDF, etc). Adding
features to specify how context maps to display may give QuickBook more
general flexibility, but dilute it's value as a specialized tool for
increasing the quality of Boost documentation.
Again, I think Reece's suggestions look great.
- james
--
__________________________________________________________
James Fowler, Open Sea Consulting
http://www.OpenSeaConsulting.com, Marietta, Georgia, USA
Do C++ Right. http://www.OpenCpp.org, opening soon!
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Boost-docs mailing list
[email protected]
Unsubscribe and other administrative requests:
https://lists.sourceforge.net/lists/listinfo/boost-docs
