Neil Hodgson wrote:
Robert Roessler:
Exposing a "ColourTo()" member function would obviate the need to use
the original Accessor-based styler at all (for normal styling needs) -
if this would be desirable. Of course, there is also the possibility
of querying the main properties DB - which also goes through the old
styler.
Unsure. One of the reasons for StyleContext was to try to get away
from potential confusion and bugs when ColourTo was available. You can
use ForwardSetState when recognizing the end of a lexeme. The two
segment loop (exit state, enter state) as used in LexCPP works quite
well although there are often some other bits needed in the loop.
Well, the bottom of *my* "while (sc.More()) {" loop looks like:
// handle state change and char coloring as required
if (state2 >= 0)
styler.ColourTo(chColor, sc.state), sc.ChangeState(state2);
// move to next char UNLESS re-scanning current char
if (advance)
sc.Forward();
"chColor" starts each char cycle as sc.currentPos - 1, but gets bumped
when a token/construct with an "inclusive" ending is seen.
"advance" starts each char cycle as true, but gets set to false when a
token is ended be a char we want to scan again from a "default" state.
This basic architecture has not changed with the adoption of
StyleContext - my logic just happens to have independently variable
coloring ("exclusive" or "inclusive" WRT the current position) and
next character advance (or not).
I wasn't complaining about StyleContext - just providing feedback. ;)
For instance, SetState() *could* have an optional parameter which
would handle my "exclusive" / "inclusive" coloring cases... say an int
which defaults to 0 which gets added to the currentPos - 1 expression.
Speaking of "potential confusion", the fact that ForwardSetState()
"invisibly" modifies currentPos by doing the Forward() and *then*
happily uses the familiar "currentPos - 1" seems a bit... potentially
confusing.
But hey, having a "SetStateAndAdvance()" function with defaulting
optional parameters controlling how much is painted and whether or not
a Forward() is done afterwards would solve everything! :)
I am just repackaging one of the things you say from time to time -
that bundling too much into "macro" operations can make them very
useful for a specific processing/usage model, but less so in the
general case... although I *do* think my slightly modified SetState()
would be nice to have.
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
