This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5079/

On August 22nd, 2010, 8:15 p.m., Alexander Rieder wrote:

Hi, i haven't looked at the code yet, but in its current form the patch doesn't compile, as you try to include the non-existent "dbhighlighter.h" in octavehighlighter.h and sagehighlighter.h, and "highlightdatabase.h" in octavebackend.cpp.

On August 23rd, 2010, 6:17 p.m., Miha Cancula wrote:

I fixed the wrong includes, and I think the correct patch is up now.

Hi, (i haven't tried the new patch, is it any different except for the includes?) some initial comments: - Octave Highlighter: operators, keywords variables are members but don't have m_ prefix. On purpose? - Sage Highlighter needs newline at end of file - use kDebug instead of qDebug (in DBHighlighter.cpp) - personally i'd like it better if you'd use a QList<HighlightingRule> as it was before instead of a QHash for the regexps, as you only need to iterate over them, and no lookup based on keys. (or is there any special reason for using a QHash?) - indentations in sagehighlighter for keywords are a bit weird - apidocs should be added (but those were already missing before) Other than that, the patch looks good, and the performance is definately a lot better. I really like the fact that the API is completely independent of the underlying implementation(as in no QHash specific code in the headers).

- Alexander

On August 22nd, 2010, 9:06 p.m., Miha Cancula wrote:

Review request for KDE-Edu and Alexander Rieder. By Miha Cancula. Updated 2010-08-22 21:06:23 Description As discussed on email, I implemented a different approach to highlighting in Cantor. I'd like some feedback before committing it. I introduced additional API in DefaultHighlighter and moved most of the logic in it, so the individual backend-specific highlighters only specify conditions (either QString or QRegExp) and matching text formats. The code looks much cleaner this way. As Alexander and Oleksiy already determined, breaking the text into words and looking for these words is faster than iterating over a huge list of regexes and looking for each of them in the text. That's why functions, variables and keywords are implemented this way. OTOH, thing like comments and strings are easier done using Regexes, so this functionality is still there. The implementation uses a QHash<QString, QTextCharFormat> and a QHash<QRegExp, QTextCharFormat>. If anyone knows of a way to make it faster, please say so. I also updated highlighters for Octave, Maxima and Sage to use the word-based API as much as possible. Most of their code was also removed, because it's now in DefaultHighlighter. I left R alone because Oleksiy's work is not yet in trunk. Testing I tested Maxima and Sage and they seem to be faster than before for large blocks. I used to have problems with non-smooth scrolling in Octave due to the large number of functions, but now it feels normal. I didn't notice any regressions (yet). It all works both on trunk and 4.4. Diffs /trunk/KDE/kdeedu/cantor/src/backends/maxima/maximahighlighter.h (1166707) /trunk/KDE/kdeedu/cantor/src/backends/maxima/maximahighlighter.cpp (1166707) /trunk/KDE/kdeedu/cantor/src/backends/octave/octavehighlighter.h (1166707) /trunk/KDE/kdeedu/cantor/src/backends/octave/octavehighlighter.cpp (1166707) /trunk/KDE/kdeedu/cantor/src/backends/sage/sagehighlighter.h (1166707) /trunk/KDE/kdeedu/cantor/src/backends/sage/sagehighlighter.cpp (1166707) /trunk/KDE/kdeedu/cantor/src/lib/defaulthighlighter.h (1166707) /trunk/KDE/kdeedu/cantor/src/lib/defaulthighlighter.cpp (1166707) View Diff