Subject: Vim's future ? - msg#00031

Hi all,

I am the guy behind the port of gvim to KDE and the implementation
of a KDE vim component (see http://www.freehackers.org/kvim/)

Warning, this is a huge personal opinion, based on the experience I have had
with vim.

I think current vim's development is going on the wrong path. One stated
goal
of vim is to not become like emacs: vim doesn't want to include every
possible
feature one could dream of. But currentely, vim is doing that. I see more
and
more code added to vim, which, in my opinion, should not belong to vim
itself.

During the development of our kvim and vim KDE component, we faced the
following problems:

- the external controlling of vim is poor: I am thinking mainly about the
client/server stuff, but I have also heard that the scriptability is
very limited if you don't want to use vim's script engine.

- vim is strongly tied to its current user interface:
-> the processing of events is blocking. This was ok for a text only
vim but it creates numerous problems for a gui vim or a vim
component.

-> wrong abstractions for gui stuff: Vim tries to define an abstract
layer for every widget. The result is that the layer is as powerful
as
the poorest gui toolkit used. And most of the facilities of every
toolkit can not be used. The use of the character '|' as a vertical
splitter is nice for a text based vim, but completely strange in a
graphical application. All toolkits already have a splitter widget.

-> it is very difficult to use vim as a gui component, without menu
and
toolbars.

- some interfaces of vim are interesting but not versatile enough: I had the
problem when I wanted to use the quickfix mode with two different program
at
the same time. Quickfix mode works with only one program at the same time.
This is not the only place where vim has a an interesting but too limited
feature.

All these problems made it very difficult for us to use vim in KDevelop or
in
KDE. We had to use hacks and things are still not guaranteed to work
properly.

We have managed to have vim embedded into a Qt widget, but the focus is not
working properly (a deep X problem). It looks very difficult for us to have
two
vim separate windows on the same text. The menu and toolbar must be
explicitely
disabled in the launching of the vim component: we must start it with

"vim -g --cmd --servername <serverName> -c source <kvimscript>
--cmd ':set guioptions-=m' -c 'set guioptions-=m'
--cmd ':set guioptions-=T' -c ':set guioptions-=T'".

As you see, one could hope for something cleaner.


One interesting stuff that we planned to do with the kvim component was to
have
it integrated into Kate (also named KWrite). Kate is a kind of generic text
editor framework (like UltraEdit on windows). It manages all kind of things
that are not directly related to editing a text file: agregating files into
a
project, grepping files, source control, ... The editing part of a file is
provided as a KDE editor component. It will be very difficult to use our vim
component with Kate because of all the problems I already mention (and a few
non vim related others).

Honestly, I am thinking about starting a vi clone for KDE, because it would
be
easier to redevelop a vim from scratch using Qt than to modify the current
vim
to fit into what we need. However, I really prefer relying on a stable
established reliable codebase, from the vim project itself.

You may well say that you don't care about KDE (or Gnome) vim component. I
find
it cool to have vim available as a graphical editor component. It is like a
second birth for the editor. And more importantely, this problem is more
general than just the KDE vim component, which is why I am posting here.

I would summerize the current vim like that:
- old codebase
- stable
- monolithic
- terminal oriented.

The reason why vim has a monolithic old terminal-oriented codebase is quite
obvious: this is the way vim was born. But I think it is important to now
move
away from this architecture to something more modern and versatile.

What I suggest is to separate vim into three or more projects:

1. the core vim
---------------
This is the backend code for vim. This contains vim's intelligence: key
handling, script syntax, vi-compatibility, ... It should be small,
abstracted
at maximum. This core component would be unusable alone. But it would
provide
many facilities to use it in many different way: vim application or vim
component.

This core vim would fix the problem we had with the vim component. It should
have a non-blocking event processing loop and should be easy to control
entirely from another process.


2. Vim UI:
----------

This is the part that would turn the core vim into a vim application. The
existing UI would be reintroduced here, with some improvements: text UI,
Gtk,
Athena, X11, KDE, Windows, ...


3. Vim framework:
-----------------

This is where I would put all the features that do not belong directly to
the
previous parts. The quickfix mode and the grep mode would be implemented
here
for example. They would be implemented using the vim UI and the core Vim.
Vimdiff would also fit there. This part could probably be splitted into many
plugins. Plugins would replace the selection of compilation options that vim
currentely uses to determine its set of features.


I hope this simple scheme carries what I mean. The interest is that you can
have a minimum vim engine that anybody could use and improve without
changing
anything. As vim is quite stable now, I would not expect this engine to
evolve
a lot over the time.

Many of the improvements that vim is currentely seing would go in the third
part. Isolating things cleanly would make it easier for people to contribute
to
vim. Currentely, vim is so monolithic that it is difficult to contribute
without reading a lot of code.

We would be able to provide a good KDE vim that is rock-solid, and so would
other projects. Vim could integrate into many IDE.

I know this requires a huge change in the way vim is currentely
architectured
and developed. But I think it is really worth it. It would allow a big code
clean-up and separation. The result will be wider use of vim, easier way to
fix
bugs, easier way to get into vim development.

Current vim code is usually composed of very big C files with no header
files.
This is a pity because header file are the best place to document functions.
Reading a set of documented header files, you understand very quickly the
role
of the functions there. Currentely, you must read huge amount of source code
to
get the same effect.

So, what do you think ?

Philippe
###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/