On Removing an Element from a List

Recently, there was a very good blog about The Importance of Mentoring. It was mentioned that the 3200 slocs of the gsoc projects could be cut down to 500 slocs, doing exactly the same thing.

While hunting some crashes in the new code folding code from the last gsoc project, I obviously had a closer look on how things are implemented. The code folding uses a simple tree structure. Nodes can be added, removed or moved around. So I stumbled over the following code:

01 // removes it from children list (QVector)
02 bool SomeClass::removeItem(Item* it)
03 {
04   bool found = false;
05   int i;
07   for (i = 0 ; i < children.size(); ++i) {
08     if (children[i] == it) {
09       found = true;
10       break;
11     }
12   }
14   if (found) {
15     children.remove(i);
16     return true;
17   }
19   return false;
20 }

This code appears several times in different locations. It can easily be rewritten as

01 // removes it from children list (QVector)
02 bool SomeClass::removeItem(Item* it)
03 {
04   int i = children.indexOf(it);
05   if (i != -1) {
06     children.remove(i);
07   }
09   return i != -1;
10 }

So without much work, the code is reduced to the half. Diving further into the code, I stumbled over a class KateDocumentPosition. This class is a line/column tuple representing a position in the document. It features operators like <, >, for convenience. Now you may guess it: Kate Part is a text editor using “document positions”all over the place, e.g. for the cursor, the text selection, bracket matching, search & replace and what not. In fact, there is no way around using line/column tuples as position markers. Thus, it should not be surprising that we have a public class called KTextEditor::Cursor, featuring everything what KateDocumentPosition implements (and more). The Cursor class is basically used everywhere, and it works as expected (our unit test rely on it, too). There is no need to duplicate the code. This probably happened because the student was not aware of it.

Martin writes “Be prepared for the worst“. Well, true. In this case, the project was successful and the new code folding works better than the old one (after fixing the crashes). Now if you are a gsoc student reading this blog, don’t feel discouraged. Rather feel encouraged to communicate with the developers a lot, e.g. by discussions on the mailing list :-)

Append Newline at End of File

In KDE SC 4.9, Kate Part will have an option in the Open/Save config tab called

[ ] Append newline at end of file on save

By default (and Kate tradition), this option is off. You can also use the document variable (modeline) newline-at-eof [bool], either in the file itself, in a .kateconfig file, or in the “Modes & Filetypes” config page. If a newline was added, it is visible only after reloading the document. This finally fixes wish #256134.

Some Kate Color Schemas

As already mentioned, Kate Part much better chooses colors from the default KDE color palette configured in System Settings in upcoming KDE SC 4.9. As teaser, here are some examples – hope you like it.

Default “Oxygen” Color Schema

Default “Obsidian Coast” Color Schema 

Dark “Vim” Color Schema

Note: The yellow search background comes from the “Highlight Selection” plugin, which is still a hard-coded yellow. Kate Part’s “Search & Replace”chooses more fitting highlight colors for matching and replaced text.