The SynEdit (or rather its predecessor mwEdit) project was started exactly because a standard rich edit control is a very bad fit for syntax highlighting.
A rich edit control works by storing the contained text in chunks with formatting information for each of the text chunks. Now imagine a syntax highlighting control for Pascal, built on top of it. Inserting a {
as the first character of the text will need to scan the whole text until the first }
that is not inside a string, and loop through all chunks until the one containing the }
, changing the formatting of the text to the formatting for multiline comments, then re-highlight the rest of the text. And deleting the inserted character or undoing the edit will similarly require the whole text to be re-highlighted. Now doing that several times a second for fast typing proved to be impossible to do in a fast and flicker-free manner on the machines of the late nineties.
So all fast syntax highlighting edit controls are implemented as custom edit controls, not as descendents of Windows standard controls. They implement all the text storage, text drawing and editing for themselves. Generally a number of predefined text attributes (for keywords, comments, symbols, numbers and so on) are used, and for each visible character the text attribute to be used is determined, then for drawing text the font and colour attributes are set and all characters with the same attribute are painted.
There are basically two ways to do that, first one is to calculate highlighting information once and store information for each character in the text (that's how for example the Scintilla text control works), the other one is to rescan the text every time it needs to be painted (that's how SynEdit works). SynEdit optimizes that by storing the initial state for each line, so to paint the lines 1000 to 1010 it doesn't need to rescan from the first line, it initializes the current syntax highlighter with the saved state for line 1000 and scans from there.
Storing information about each character needs more space, but has several benefits. First text can be highlighted even when the highlighting information can not be determined from the text alone, for example log messages with time stamps; and second the per-character data can be used to store additional information, for example for text folding, or for information which characters were inserted or changed.
I don't think it is realistic today to implement a syntax highlighting control from scratch, for arbitrary text sizes, complete with Unicode support, full undo/redo, multiple views, code folding etc. as a one-person-effort. Or maybe it can be done, but the person would need to be familiar with the internals of existing highlighting controls, if only to not make the mistakes or sub-optimal decisions that were made while creating them.