Joel de Guzman wrote:Reece Dunn wrote:
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!
Exactly. BoostBook uses a different mechanism because it scans directories from the build tree.
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 don't think you need something similar to BoostBuild. The reason is that BoostBuild has a different mechanism to scan for jam files. By providing the following rules for locating a qbk file (in the order the directories are searched):
1. Search the path of the current qbk file being processed;
2. Search the paths specified from the command line;
3. Search a default directory (where default.qbk is located).
This would then allow you to provide a default.qbk in either the current search path or one of the paths from the command line, thus overriding the default behaviour.
It may also be advisable to allow environment variables in the include path, allowing
-- default.qbk
[include (QUICKBOOK_ROOT)/default.qbk] # import default qbk behaviour
[include syntaxes/java.qbk] # add Java syntax highlighting
Alternatively, you could add quickbook_root and boost_root as predefined values. I can't remember the exact QuickBook syntax, but it would behave like a def statement:
[def boost_root $(BOOST_ROOT)]
[def quickbook_root $(boost_root)/tools/quickbook]
This would have the advantages of: 1. fitting in with the existing quickbook preprocessing mechanism; 2. allow you to use other def aliases in an include statement; 3. not require special environment variable handling and support.
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.
This was a braindead moment on my part! Ignore the colour specification element of my suggestion. Of course CSS is definitely the way to do specify the styling.
Regards, Reece
------------------------------------------------------- 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
