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!
begin:vcard fn:James Fowler n:Fowler;James org:Open Sea Consulting adr:;;1486 Surf Court;Marietta;GA;30066;USA email;internet:[EMAIL PROTECTED] title:Principal Consultant tel;work:770-714-3124 tel;fax:770-852-2709 tel;home:770-852-2720 url:http://www.openseaconsulting.com version:2.1 end:vcard
