On Jun 14, 10:17 am, "Edward K. Ream" <[email protected]> wrote:
> I have no clear picture, at present,
> about whether this is a trivial, easy, hard or intractable problem :-)
I'm on a roll. The more I consider possibilities, the more I am
beginning to think that the new scheme will be "straightforward",
perhaps even "easy" in some sense.
First, let's state the problem simply and clearly.
1. We want our colorizer to take *only* what Qt gives us, namely the
contents of a line, and the starting state of the line.
We do not want to know the context of the line. We do not want to do
any scanning backwards before the start of the line or forwards past
the end of the line. As far as our colorizer is concerned, the line
is all there is, all the time.
2. The output of our algorithm will be calls that will indicate the
coloring of the characters *on that localized line*.
Again, where the line fits into the rest of the widget's text must be
of absolutely no concern to our colorizer.
The exciting thing is I think it's possible to make this happen.
Suppose we do have such a scheme. Three, no four, no five kinds of
bugs are still possible:
A. Bugs in QSyntaxHighlighter.
B. Failure to init QSyntaxHighlighter when major changes are made to
body text.
C. Bugs in the colorizer main line.
D. Bugs in the jedit matchers or restarters.
E. Bugs in the mode files.
The exciting thing is that bugs of type C and D can easily be fixed.
Unit tests are possible.
BTW, speaking of unit tests, it might be useful to define a "unittest"
mode (language) that will exercise the colorizer fully. But I
digress.
Let's repeat the fundamental problem: Given *only* the starting state
of a line and the line itself, we want to indicate 1) which characters
of the line are to be colored and 2) what the ending state of the line
is.
To be continued.
Edward
>
> Still, I'm happy to have new thoughts on this subject. All comments
> welcome. Life is good :-)
> QQQ
>
> And some further comments:
>
> > No doubt you notice the pattern. Only *multi-line* patterns can generate a
> > state other than 'plain'.
>
> To clarify, states define the coloring state at the *start* of a line.
> Even
> if the cursor is in the middle of an id (or python comment, or any
> other
> token), we never need a state for in-id, in-comment, etc. This is an
> important simplification.
>
> > I have a hunch something much simpler might work. Naturally, this won't
> > happen until the Leo 4.7 release cycle.
>
> Or perhaps the 4.6.1 release. If these brewing ideas work, it would be
> well
> worth a minor "official" release.
>
> I'll continue this in replies to this thread.
>
> Edward
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~----------~----~----~----~------~----~------~--~---
