After month of battling, first with the audio transcription, then with the english correction, and finally with the french translation, my Trolltech interview finally gets published: English version and French version
I am the first one to say that there is no more stupid project than writing a source editor. There are plenty, they work good enough, you should better focus on something more useful. Even more stupid would be to rewrite one major editor like Emacs or GVim. Despite that, I am now engaged in Yzis, the rewriting of a vi-like editor.
The problem we had with gvim is that when doing KVim, we found many limitations in the way graphics are handled in gvim. It prevented us to make a good kpart component for KDE. Working with the source was a nightmare and the author was not willing to ease the task for us: only bugfixing and nothing else are accepted in gvim.
So, we started yzis. So far I have contributed the test suite and the undo code. Despite gvim being very advanced, I am confident that we can eventually bring a better editor. The key of success for yzis vs gvim:
- object oriented code (yes, this is C++) that cleanly separate features: gvim is coded in C, a big part of it with pre-ansi syntax.
- documentation in the header file: gvim has no such things as header-file
- easy-access: it is very easy to add a new command to yzis already, and it will only get easier
- strong test suite to allow easy maintainability and no regression: this is where gvim fails. Currently, Bram does not want to touch gvim too much because he is afraid of breaking anything. We won't have this problem. One of my coworker says that a good test suite is more valuable than code. With the test suite, you can write the code again and be sure get what you want.
- seperation of vi-engine and GUI code: a problem we had with gvim is that the engine is so tied to the text frontend that it is difficult to use it in graphical environments. There is no such thing as event-loop which forced us to do twisted manipulations (sometimes eating all the CPU)
On the drawbacks side, yzis (even the engine) depends on Qt because we did not want to deal with unicode problems. However, we use very little of Qt for the backend (mainly QString, QMap and QList) and it could be replaced with a std::string if one is motivated. There is no windows port yet, but I am investigating the porting of tinyQ on windows, to have at least the backend compiling.
GVim is a great editor so we will have a long way before competing with him. However, we have an easier to maintain codebase. We can not borrow code but we are probably going to implement compabilibilities features, like re-using the syntax highlighting files.
We are heading to Milestone 1 in one week. Wait and see...