You could call this a response to bug 28: Leo hangs when a node with too
large body is selected
https://github.com/leo-editor/leo-editor/issues/28
In general, the strategy must be to accept a slightly slower overall rate
of syntax coloring in return for what we hope will be far greater response
time to user actions. One non-negotiable goal will be to keep Leo's
already-too-complex syntax colorizing code almost completely unchanged.
To get better response time, we must break the syntax coloring into pieces,
say chunks of 1000 lines or less. The simplest thing that could possibly
work would be to colorize these chunks at idle time. Alas, there is *no
way* to cause QSyntaxHighlighter to break up the task into smaller chunks.
It just wasn't designed to do that. Later, we'll see exactly why this is
so.
The only solution is to transliterate QSyntaxHighlighter into Python! I
have already done this using Leo's c-to-python command. The new class is
called PythonQSyntaxHighlighter and is now in qtGui.py.
The code passes pylint, but surely there are many serious bugs in it. It
is not connected *in any way* to Leo's actual code--it exists *only* for
experimentation. Still, it should be possible to get this new class working
reliably. Here is an overview of what must be done:
1. applyFormatChanges is most important, most complicated method. It
completes the formatting (specified by the calls to setFormat) in the
underlying text document.
2. reformatBlocks drives the formatting process. The code is
straightforward. The heart of this code is::
# Continue highlighting until states match.
forceHighlightOfNextBlock = False
while block.isValid() and (block.position()<endPosition or
forceHighlightOfNextBlock):
stateBeforeHighlight = block.userState()
self.reformatBlock(block)
forceHighlightOfNextBlock =
(block.userState()!=stateBeforeHighlight)
block = block.next()
self.formatChanges = []
This code is what makes QSyntaxHighlighter so fast, *after* the initial
full recolor, that is :-) It colorizes the bare minimum of lines.
This is the code that must change to break colorizing into chunks. Doing
so should be straightforward.
BTW, Leo's existing syntax coloring code computes the proper ending state
for each colorized line. It's a complex task, but it makes the code above
fast.
===== Summary and conclusions
Most of the code in QSyntaxHighlighter is simple, or would be if it weren't
written in C++ :-) The transliteration got rid of a lot of blah, blah,
blah, but surely has introduced serious errors.
applyFormatChanges is the only difficult code. It won't be *that* hard to
test.
Rewriting reformatBlocks is the *only* way to break syntax coloring into
pieces.
So that's it. The best solution to bug 28 is to color large text in small
pieces, thereby allowing Leo to remain responsive.
Edward
P.S. Before fixing bug 28, I must fix some very serious problems with tab
completion and the change command. These bugs are urgent, and were
probably introduced by the grand reorganization of the k.getArg code.
P.P.S. Doing syntax coloring in a background process would gain nothing,
even if it were possible, which it almost surely isn't :-)
P.P.P.S. <rant>
It is infuriating that applyFormatChanges and reformatBlocks are private
(members of the QSyntaxHighlighterPrivate class).
Yeah, let's hide the really useful stuff. What a bleeping great idea.
Stronger language deleted :-)
</rant>
EKR
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
