Re: [Boost-docs] Re: Dynamically Loadable Syntax Highighters [ Was Re: [ANN] QuickBook 1.0 now in boost/tools]

[James Fowler]

Eric Niebler wrote: James Fowler wrote:     * [table .notitile ...] and [variablelist .notitle ...] allow tables I'm not partial to the magic ".notitle" string. I would prefer it if the title were merely optional for tables and variablelists. Should be easy, no? I'm not particularly crazy about ".notitle" myself,  but here's a quick explanation of the rationale: It required no changes outside of the table_action and variablelist_action operator()(), and leverages the current behavior of the grammar (some title is always defined) The current parser seemed to imply that you could create an "empty" title, and I tried to work with that instead of ".notitle", but I tried a few different patterns in a test .qbk file sometimes the table disappeared entirely sometimes interpreted the first row as the title (even though there was a newline) I stopped trying to figure this out based on the existing parser definition, because even if there is a form that "works" it would be far too fragile I haven't done enough with the Spirit parsers to be confident that I could tweak this without risking side effects that will probably change over time :) but I'm writing docs now (which I'll be happy to change if we find a better way) I don't know if it would be easy for me at this point.  Not sure I can risk trying to find out... Within reason, I think it's worth a slight increase in verbosity if it benefits clarity, especially for projects like Boost based on collaborative efforts.   I might prefer writing [table \n [header1] [header2] ...], but I'd rather read something more informative, like [table .notitile\n [header1] [header2] ...], when trying to understand what someone else wrote.  While there might be better ways to communicate such intent than ".notitle" (perhaps [anonymous_table ...]),  just omitting the title is convenient for the original author but adds ever so slightly to the learning curve necessary for someone new to QuickBook to understand the intent of existing qbk docs.  My main concern here is striking a balance between simplicity for the original authors and clarity for everyone else. Make sense?  I guess my idea of the ideal here is for the syntax of QuickBook source ("qbk") files to make them inherently, er,  "well documented". - james -- __________________________________________________________ James Fowler, Open Sea Consulting http://www.OpenSeaConsulting.com, Marietta, Georgia, USA Do C++ Right. http://www.OpenCpp.org, opening soon!