[Interest] Guide me through the Qt offerings for GUIs
roland at logikalsolutions.com
Tue Apr 20 21:03:06 CEST 2021
On 4/20/21 9:18 AM, Matthew Woehlke wrote:
> On 20/04/2021 09.10, Roland Hughes wrote:
>> Close on the heels of that "Why are they highlighting the whole
>> thing?" when you only need the currently visible lines and possibly a
>> screen up/down. Open up a 10,000 line source file in editors using
>> even on an i5-gen3 and you are almost instantly taken to the line you
>> were on with perfect syntax highlighting.
> Frankly, I am skeptical. At best I think you are misrepresenting the
> It's well known that you *have* to highlight the whole file, at least
> to the current position, for accurate ("perfect") highlighting. At
> least in the general case. There may be some files and/or syntaxes for
> which that it not the case, but vim has had partial highlighting for
> almost forever, and I've seen it drop the ball on plenty of occasions,
> because something earlier in the file changes correct highlighting for
> the visible part.
No, it's not well known or even accurate. IF one is taking a student
type approach and attempting to use regular expressions all mushed
together as one nasty bundle, the statement is true.
Let's look at three editors that seem to do it right.
While some may/may not know about Qt classes, they all know about
Now lets pick on Featherpad trying to do it "the Qt way"
Obviously not right. Probably passable for many, but as language syntax
increases in complexity both accuracy and performance degrade.
To highlight only the visible subset one simply needs to know the outer
most enclosing boundaries. We had to do this stuff back when I was
working on a Masters in the 1980s. Instructor for compiler design made
us do this stuff in both Assembler and Algol (don't ask!)
There are multiple architectural problems with QPlainTextEdit. Most
notably, it completely abandoned "plain text." Instead we have graphics
components wedged in with private classes one can't get to and in
general trying to stuff everything into a single class with much of it
locked away. Adding insult to injury is the single-thread-i-ness of main
Text isn't a stream. It isn't a blob and it isn't a byte array. A text
file is a sequence of variable length text records. Each record has an
end-of-record marker depending on the OS and disk storage method. Some
will have 0x0A (linefeed); others 0x0A 0X0D (linefeed carriage return);
a very rare few will have 0x0D 0x0A (Carriage return linefeed) [Despite
what people say, it's almost always LF CR in a file. The CR LF sequence
was used almost exclusively for transmission to remote line printers
without flow control because you needed to buy time for the print head
to get to the left margin.]
The last rarity on the original ASCII systems is just 0x0D. I forget
where that got used most often. (EBCDIC is a completely different can of
At any rate, to successfully syntax highlight a narrow window all you
really need to know is the outermost enclosing scope which gets
determined during load and stored in a structure.
Well, anyway, QPlainTextEdit tried to mush everything down into one
layer, at least everything that mattered. The single-thread-i-ness of
the main event loop causes everything to monkey pile in the event queue
all waiting their turn to paint.
For a couple hundred lines on a fast machine it is close enough for hand
grenades. For editing anything of any significance, no.
I feel what's-his-name's pain with Featherpad. Trying to speed things up
by tweaking the regular expression stuff, always hitting a performance
wall. Thank God he is only doing a small handful of colors instead of
the robust syntax highlighting found in Sublime and Emacs. He could be
looking at ten minute file loads.
At the core of the class is the wrong object. The needed higher level
objects also aren't there.
A text editor, even a GUI one, is still a line editor.
Roland Hughes, President
More information about the Interest