James Fowler wrote:
Joel de Guzman wrote:
We need a program options flag for this which defaults
to 4 spaces. Thoughts?
It's converting tabs to four spaces now, which seems to be the
"preferred" indent scheme for Boost. The recommended approach to tabs
in Boost code is to simply avoid them
<http://www.boost.org/more/lib_guide.htm#Tabs>, which IMHO is the right
thing to do for Boost. I'm a little wary of adding flags or options
which make it easier to support tabs which probably shouldn't be there
in the first place in any code included in Boost docs, but we can also
deal with that by just issuing nasty warnings whenever the highlighting
process encounters tabs... Anyhow, the "flaky" part is that the current
tab expansion is simply "tab" -> "space space space space", which works
pretty well for leading indentation, but thrashes stuff like
[...]
because it's not smart enough to replace a tab with "enough spaces to
reach the next tab stop". We can handle this through doing tab
expansion just before we process the highlighting, but this isn't really
a high priority for me. If anyone is interested, I can point them to
where it would need to go, or graft it in given a tab expansion
algorithm which works on standard iterators or std::string.
Right. In light of this, I am now leaning towards simply issuing
a warning and not doing any tab to space conversion at all.
I think that's the right way to go.
Don't you think we ought to just standardize on a quickbook
inline syntax for this?
Probably, with a few comments:
* The inline syntax needs to maintain the level of clarity and
simplicity of Thomas's implementation. Perhaps the best approach
is to just keep using what Thomas put together, but add higher
level directives (maybe [begin_highlight_def ...] ...
[end_highlight_def]) which can extract the contents and pass them
to the highlight "load" logic. This should be pretty simple, if
the "load" logic is smart enough to append to existing schemes. I
_think_ that's the case, but I don't know that anyone's ever tried
it yet. FWIW, this can be tested with [include
more_highlights.hlt] - just make sure that afterwards both the new
and the prior (C++ and python) highlight schemes work properly.
If they do, then the rest is easy.
Right. Multi-level grammar. That should work, but is it the right
thing to do? I don't see any reason why we can't come up with
an equally high level of clarity using qbk syntax. I believe
Reece suggested a few.
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
