This is a long, detailed post. It's not an Engineering Notebook post because it may be of general interest. I hope to get comments from the usual suspects.
I have spent several pleasant days making the Scintilla widget pretty much fully functional. In the process, I have learned enough about SciTe/Scintilla "properties" to make Scite itself, and Leo's Scintilla body pane display text almost exact as Leo's legacy QTextBrowser text pane does. ===== The big picture To state my conclusions first: 1. It is now possible to use the Scintilla widget for production work. I did so for a day or two--it was motivation to fix glitches and annoyances :-) 2. Nevertheless, using the Scintilla widget will not improve Leo substantially. Quite the reverse, further work on Leo's Scintilla widget would be unwise. Here's why: ===== Why supporting Scintilla is unwise 1. As a general principle, it is unwise to support two different, fully equivalent, ways of doing the same thing. I will continue to use QTextBrowser: I will have little motivation to improve the Scintilla widget. 2. Syntax coloring is a problem. At present, Leo's Scintilla's body pane supports only Python coloring. It would be relatively easy to support the various language that Scintilla supports, but Scintilla does not support all of the languages that Leo presently supports. Imo, the worst omission is reStructuredText. Leo simply must be able to color rST! It is easy to create custom Scintilla lexers (colorizers)--I created one to support @nocolor. Alas, it does not appear possible to over-ride, say, the Python lexer to add support coloring of section references. I haven't asked the Neil Hodgson, Scintilla's author, about doing this, so I can't say for sure, but the odds seem against. In any case, the issue is moot. The only way to support *all* of Leo's existing languages would be to use Leo's *existing* colorizer code. Yes, adapting that code to Scintilla would likely be possible now that I have a version of QSyntaxHighlighter written in Python, but that hardly matters... This is Irony Number 1: I was attracted to Scintilla because syntax coloring is lightning fast. Now it turns out that in most (all?) cases Leo would have to use Leo's legacy colorizers! This isn't horrible now that syntax coloring happens in the background, but still: using Scintilla won't speed colorizing! 3. Scintilla is safer than QTextEdit because it loads text more *slowly* than QTextEdit. This is Irony Number 2: I was attracted to Scintilla because it *seemed* to load text more quickly than QTextEdit. In fact, the reverse is true, as can be seen by adopting Terry's excellent benchmark script to use Scintilla rather than QTextEdit. Scintilla (properly!) waits until all text has been loaded before allowing the user to edit it. 4. Scintilla does not support Qt style sheets. Scintilla uses an entirely different configuration system than does QTextEdit. Imo, this is the real show-stopper. Leo's settings are baroque enough without having to explain *two* sets of settings: one for QTextEdit and one for QsciScintilla. Supporting two kinds of settings would dilute developer attention, and would increase user's settings agony without adding *anything* of substance. Aside: I was able to tweak Scintilla's properties to make it look like exactly the way the QTextEdit widget looks. This demonstrated that (at least to my geriatric eyes) Scintilla's text-handling capabilities are the equal of Qt's. That's nice to know, but it is hardly a reason to double our settings trouble! ===== Working around the "killer" QTextEdit bug Now that Scintilla does not seem much of a "salvation", we must, somehow, work around the QTextEdit loss-of-data bug that Terry's benchmark script implicitly demonstrates. My full bug report is: https://bugreports.qt-project.org/browse/QTBUG-41153 Actually, I think "big text" buttons are a pretty good start: https://groups.google.com/d/msg/leo-editor/XTonZ8Bvjwc/nA9szuofZ30J They will (when enabled) make it possible to zip past big nodes. The "killer" problem only happens when the use clicks the "load text" button :-) There are several possible workarounds: A. The load text button could trigger an idle-time check that will take place significantly later, maybe 2-4 seconds, perhaps even depending on the amount of text loaded. The check will warn if w.getAllText isn't the same as p.b. No real details yet. B. The load text could disable all text operations on the text until we are *sure* that it has loaded correctly. This might be safer, but it could be hard to do cleanly. C. For now, the workaround will be to warn people to wait when hitting the "load text" button. Hehe. ===== Summary The killer QTextEdit bug is extremely serious, but replacing QTextEdit with QsciScintilla will dilute developer resources (waste our time) and will offer both worse performance and fewer features than at present. Ironic, indeed. Instead, Leo will employ one of various more-or-less-safe workarounds. These workarounds are needed only for big nodes. Your comments, please, Amigos. 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
