# Introduction

## About Yzis

Yzis a brand new editor inspired by vim. Yzis aims to be a powerful, fast editor with all of Vim's features and hopefully, at some point, more.

In Yzis, the core editing functionality is placed in a library, and interfaces are written on top of that. As of now, there are frontends for KDE and ncurses. Especially the KDE-interface provides an easy-to-use interface for users and allows you to have tabs for different buffers and a GUI that allows you to change things like colour schemes and syntax highlighting easily, while still letting (g)vim users feel at home.

By using the powerful scripting language Lua, you can also easily extend yzis' functionality with scripts.

With an editing-engine clearly separated from the GUI, the different interfaces can be written to be closely integrated in their respective environments. The KDE frontend, kyzis, can be seamlessly embedded in KDE apps like Kdevelop.

libyzis is published under the terms of the LGPL.

kyzis and nyzis are published under the terms of the GPL.

The ncurses GUI.

The KDE GUI.

## Requirements

- Qt 3.x or Qt 4.0(strictly superior a beta1 :)

- Lua 5.x

- For kyzis : KDE 3.2.x

- For nyzis : NCurses 5 _WITH_ wide characters support (USE unicode on gentoo)

- Optionnally : pslib (pslib.sf.net)

## History

Before working on Yzis, the authors (Mickael Marchand, Thomas Capricelli and Philippe Fremy) had been working on GVim. GVim is clearly the best vi compatible editor today. It contains tons of features, which are very clear improvements upon the original vi: visual selection, unlimited undo, powerful syntax highlighting, script language, splitted windows, ...

We did two things with GVim. First, we ported it on KDE and created KVim. The second step was to make KVim embeddable as an editor component into any KDE application. The idea was to be able to use a vi editor anywhere: in KDevelop, in Kate, in KMail, ... We managed to complete both tasks but the second one was very difficult to achieve and a number of problems could not be overcome. For example, kvim can not have multiple windows on the same buffer, and thus won't integrate in Kate.

While working with the gvim code base, we have been comfronted with a growing amount of difficulites: - there is a huge pile of C files without much documentation. - it is difficult to find one's way through the code. - the code was written in C and has very little abstraction, which make it difficult to follow. - the vi engine is tied to the concept of console editor. We have to add hacks after hacks to make it work as a graphical component (for example, we need to fork a process, embed a graphical window, and run an event loop at full speed while still not taking the whole CPU to just make the component work). - the main author of GVim is very reluctant to add any small change, even those that won't affect the current behaviour - the codebase is very big and the author does not want to introduce any new feature, in fear of breaking something.

So, on one side we had implementation limitations and problems, on the other side it was not possible to do any new developments on the editor. We discussed that with the GVim team and came to the conclusion that it was not possible to work with GVim to have a vi-like editor in KDE as a good component.

At this point, the decision was simple. Either spend lot of time in working around limitations of GVim, or dropping the idea of a good vi editor component for KDE or start a new vi editor. Kudos to Thomas Capricelli and Mickael Marchand who took over the third decision. This decision was taken shortly before Fosdem 2003. The design documents and the name were hacked during the Fosdem.

They put up a website, a subversion server, mailing lists and started coding. To avoid the many problems of gvim, we took the following decisions:

1. clearly separate the vi engine from the gui

2. use C++ to provide a clean design

3. abstract the views, the buffer and the gui in the engine

4. have a KDE gui

5. have a text gui

6. provide a C interface in case a hard-core C coder wants to contribute

7. use some Qt classes for the engine. Qt would bring a string class that handles unicode correctly (multibyte support is knightmare in gvim), efficient lists implementations, and other goodies. Moreover, we were very familiar and efficient with Qt.

8. Use tinyQ as a backup solution for the people not willing to link with Qt just for a few template classes.

Over the time, maintaining a C binding to C++ turn out to be quite tedious and time consuming. It would also make the code quite complicated. So the C binding was dropped and yzis started to develop slowly but steadily.

## Authors

- Mickael Marchand <mikmak@yzis.org>
- Thomas Capricelli <orzel@yzis.org>
- Philippe Fremy <phil@freehackers.org>
- Loic Pauleve <panard@inzenet.org>