
Development policies:
=====================
class names are LikeThatClass
class members are mMyMember
class structures are mystructure

Preferred indentation ?

You have to add a comment for every function you add (doxygen format)
You have to add a test for every new method of a class that already has a test
All the tests must always pass at 100% whatever change you make

It is a good practise to write the test and the feature at the same time.


Architecture:
=============

YZBuffer is the abstraction of the file being edited. All the commands that
modify the buffer should do it with one of the method of the class.

YZView is a view on a buffer. A view has a cursor but is not necessarily
visible at all times (think MDI). A buffer may have multiple views on itself,
like when a window is splitted, or even with multiple windows showing the same buffer.

YZSession is the central managing point of Yzis. Session is responsible for
creating the views and buffer. It dispatches the events of the core to the
gui. One important concept in Yzis is that it only reacts on events. This is
different from gvim, which blocks completely until it receives an event (this
is one of the reason why we started yzis, see the link history on the web
site).

In order to start a new port of yzis, you need to subclass YZBuffer, YZView
and YZSession and implement the pure virtuals functions.

When a line is changed on a buffer, the YZBuffer notifies the gui with an
InvalidateLine event. The views retrieve the event and repaint the line. When
a new character is entered, usually, the view deals with it directly by
forwarding it to the YZView::sendKey().

VI commands are separated into commands (the one you enter in the command
mode) and ex commands (the one you enter after pressing :). They are added to
the engine through the YZCommandPool (see libyzis/commands.h). Most commands
are implemented in the YZView though, because they need to know the position
of the cursor. Scripting commands can be found in libyzis/ex_lua.cpp.

