James Fowler wrote:
I just meant that the quickbook executable needs to locate (on start up) the
built in syntax highlight scheme file. The user could extend this scheme by
supplying their own scheme via the command line, or indeed by editing the
default one. It's not really a problem...
Why at startup? Why not actually load (include) dynamic syntax
definitions explicitly, something like "[sourcemode foo]" pulling in
"*/foo/.highlight_def_extension*"? This could look first in the local
directory, then search relative to a some standard lookup path (perhaps
$BOOST/tools/QuickBook/highlighters ?). It might allow for more
intelligent feedback on errors (i.e., dependency on a definition file
that isn't found). I think it could even be leveraged to allow BBv2 to
treat referenced definitions as dependencies, triggering a QuickBook
"rebuild" if the definition is updated (which might be much harder to do
otherwise, short of any change to any definition file triggering every
.qbk to get reprocessed whether or not it used that definition).
Too fancy, I think. But you do have a point. Maybe we can
start simple and build our way there.
I like it. A bit pythonish, but it's ok
Is that supposed to be a problem? ; ) I had never looked at python
until I started working with Boost, so I just kind of consider it the
Boost scripting language...
No, it's not a problem ;-) It was supposed to be a joke
to lighten up the conversation :-)
Cheers,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
-------------------------------------------------------
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
