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.

Reply via email to