The fast-colorizing branch: a revolution in syntax coloring

[Edward K. Ream]

The fast-colorizing git branch is a revolution in syntax coloring, while using the bulk of Leo's existing coloring code. The new code supports all of the languages in leo/modes.

Please test this branch for at least a day or so before being merged into the main line. Please report any problems immediately.

This branch is revolutionary in several senses:

1. It fixes, at long last #273: Qt Bug involving large text nodes.

2. It completes #365: Use pyzo syntax coloring.

3. From an engineering standpoint, it revolutionizes Leo's approach to Qt's QSyntaxHighlighter class.  In essence, everything happens automatically. When changing nodes, Leo need only re-init the underlying jEdit colorizing code so that the proper language is colorized. 

This is a stupendous advance. No need for any of the interface in the ColorizerMixin class.  No need to "lock out" coloring: it happens automatically whenever Leo's body pane changes! Heh.  As I write this I see that colorizer.colorize is no longer ever called!

I don't think I have ever misunderstood a class as badly as I have misunderstood QSyntaxHighlighter class.  Set up and used properly, it is an amazing helper. To be fair, Leo uses this class in a very unusual manner. The mistake I made was subtle, and the Qt documents don't warn against it.

The performance bug created by calling QSyntaxHighlighter explicitly caused a "series of unfortunate events" ;-) Seeing the speed pyzo's pure python syntax colorer was the key breakthrough.

Edward

[Edward K. Ream]

On Sunday, January 15, 2017 at 6:43:44 AM UTC-5, Edward K. Ream wrote:

3. From an engineering standpoint, it revolutionizes Leo's approach to Qt's QSyntaxHighlighter class.  In essence, everything happens automatically.

I have not tested this code with Python 2. This must be done before merging the branch.

Note: leo_h.rehighlight method appears never to be called.  This is weird, imo.

That's all for now.  Time to prepare for our trip back to Madison.  I'll be following your comments with interest along the way.

Edward

[Edward K. Ream]

On Sunday, January 15, 2017 at 6:53:32 AM UTC-5, Edward K. Ream wrote:

I have not tested this code with Python 2.

It turns out that colorizer.colorize is called, but only with python 2.

Once in a while I am seeing this, with both Python 3 and 2:

Internal Leo error in bodyString
not unicode: (the actual string)
Called from writeFile,makeCacheList,__get_b,bodyString

This may be a subtle result of the changes made in the LeoTree.select logic.  Off hand, I don't see why bodyString can't just convert to unicode...

I don't have time to investigate this now. Not sure how serious it is, but I don't think the branch can be merged in its present state.

Edward

[Terry Brown]

On Sun, 15 Jan 2017 04:44:11 -0800 (PST)
"Edward K. Ream" <edre...@gmail.com> wrote:

> On Sunday, January 15, 2017 at 6:53:32 AM UTC-5, Edward K. Ream wrote:
>

> *I have not tested this code with Python 2*.
> >
>
> It turns out that colorizer.colorize *is* called, but only with

> python 2.
>
> Once in a while I am seeing this, with both Python 3 and 2:
>
> Internal Leo error in bodyString
> not unicode: (the actual string)
> Called from writeFile,makeCacheList,__get_b,bodyString

Not sure that that's new - e.g. I reported it here:
https://github.com/leo-editor/leo-editor/issues/342
which I think was before Pyzo came on the scene.

Cheers -Terry

[Edward K. Ream]

On Sun, Jan 15, 2017 at 11:44 AM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> wrote:

 

> Once in a while I am seeing this, with both Python 3 and 2:
>
> Internal Leo error in bodyString
> not unicode: (the actual string)
> Called from writeFile,makeCacheList,__get_b,bodyString

Not sure that that's new - e.g. I reported it here:
https://github.com/leo-editor/leo-editor/issues/342
which I think was before Pyzo came on the scene.

​Thanks Terry.  I have just merged the fast-colorizing branch into the trunk.

Rev f8c68ea adds two calls to g.toUnicode ​in createOutlineFromCacheList. That may eliminate a few calls to g.internal_error.

Edward