A major post occurred in discussion of this bug: https://bugs.launchpad.net/leo-editor/+bug/384051
Here it is, for those not following bug: QQQ On Sun, Jun 14, 2009 at 4:07 AM, Ville M. Vainio <[email protected]> wrote: > Patch that does this attached (it colorizes the beginning of the doc, > but gives up at the end). Try it out. > > I'm still not satisfied with the performance though. I'm not satisfied with any aspect of Leo's qt syntax coloring. The code is too complex really to understand, and it doesn't work reliably. Gee, could there be a connection ? :-) Imo, a rewrite would be in order. The idea would be to better adapt the pattern-oriented jEdit matches to line-and-state oriented model used by QSyntaxHighlighter. Of course, that's what the present code does, or tries to do. Maybe we're stuck with the present code, but I have a hunch something much simpler might work. Naturally, this won't happen until the Leo 4.7 release cycle. Edward P.S. Some thinking out loud. jeditColorizer.recolor contains the main syntax coloring loop. QSyntaxHighlighter calls leoQtSyntaxHighlighter.highlightBlock, which calls recolor. The problem is that the "block" (line) orientation of highlightBlock must be reconciled with the pattern orientation of the jEdit pattern matchers. We can't abandon the pattern orientation of the jEdit pattern matchers without abandoning all the benefits of having dozens of jedit mode files. Yes, in extremis, we could punt, and do everything over. But in my mind, this defines total failure. The essence of the problem is: given line-oriented info, how do we restart the character-oriented pattern matchers? The problem is made hard (or intractable?) by the fact that cached state info is always in danger of being invalidated by the changes that triggered the recoloring in the first place. As I write this, I am reminded again of just how hard a problem this is... Hmm. Let's pretend we *did* have (really and truly) an integer state that actually defined the state at the start of a line. Note that this is *not* true at present: the "state" is actually an abbreviation for a complex g.bunch that tells how to restart the scan later. To repeat, suppose we did have a real (and simple) state. For python, only a few states suffice: - plain - in-single-triple-quote-string - in-double-triple-quote-string - in-single-quote-string - in-double-quote-string No doubt you notice the pattern. Only *multi-line* patterns can generate a state other than 'plain'. I wonder. Can we determine, from the jedit patterns, which pattern matchers can span lines? I believe we can. Suppose we assign simple state numbers 1,2,3,etc, to the span of characters returned by successful matches from those matchers? Does this help? Not directly, because it doesn't tell us how to restart the match. But surely there are relatively simple, testable, tricks that can be played here. I think we are getting warm. One Aha is that there are a finite number of jedit matchers! Quite possibly, **we can analyze each matcher** to tell how to restart it simply. For example, we could create jEdit **restarters** (one for every jedit matcher that could span a line), that would tell how to restart the scan. The great thing about such restarters is that unit tests are possible. This is intriguing, and worth more thought. It does *not* guarantee success, however. In particular, the problem of invalid cached data remains, or is transmogrified. We have to ensure that restarters always work in the presence of altered data. I have no clear picture, at present, about whether this is a trivial, easy, hard or intractable problem :-) 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 -~----------~----~----~----~------~----~------~--~---
