This is an Engineering Notebook post. Feel free to ignore.
The LeoQtColorizer class is collapsing in complexity. It might disappear
entirely!
Here, I'll discuss what has happened and what may happen, with a checklist
of things to do.
*tl;dr:* I'll continue to work in the color branch until no further
simplifications are possible. But colorizing multiple editors must also
work ;-)
I'll always use the term "*colorizer*" to mean an instance of
LeoQtColorizer.
*History*
Fixing the huge performance bug started an avalanche of code changes. The
actual fix was *not *to call LeoHighlighter.rehighlight. That in itself
eliminated several complex paths through the code.
Today I was shocked to discover that colorizer.colorize* can be a
do-nothing*! This in turn implies that c.recolor_now can be a do-nothing!
A minor corollary is that both LeoBody.recolorWidget and
LeoQtBody.recolorWidget can also be do-nothings.
In fact, all these methods are now do-nothings in the color branch.
Astounding.
Only the ctor, init and updateSyntaxColorer methods (and helpers) remain
functional in the LeoQtColorizer class.
*Further simplifications*
Only calls to c.updateSyntaxColorer exist in Leo's core, or so I think.
Furthermore, c.updateSyntaxColorer is just:
def updateSyntaxColorer(self, v):
self.frame.body.updateSyntaxColorer(v)
Oh joy. This abbreviation/indirection means we can change things in
leoColorizer.py without any effects in Leo's core. For example, we might
want per-widget colorizers, in which case the code above might become:
self.frame.body.widget.updateSyntaxColorer(v)
This is important, because Leo switches body.widget when changing body
editors.
In short, we may be able to move all LeoQtColorizer code into another class.
*Complications*
At present, multiple body editors are not colored correctly. This can
probably be fixed with a few lines of code, but finding those lines may
take awhile. There are subtle issues regarding which classes should have
colorizer members (if any), etc.
*Checklist*
[ ] Remove @bool use_syntax_coloring.
Not actually honored in the present code. It's not necessary, because using
@language plain does the same thing.
[ ] Simplify LeoQtColorizer.__init__ (not the same as init).
Some ivars are clearly not used. The question is, can everything be
eliminated? If not, it may still be possible to fold the data into the
jEdit colorer.
[ ] Eliminate the ColorizerMixin class?
An open question. No need to dwell on the pros and cons here.
Edward
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
