[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vim-dev
Subject:    RE: Vim's future ?
From:       "Michael Geddes" <mgeddes () au ! mediacommand ! com>
Date:       2002-11-05 23:44:22
[Download RAW message or body]

Hi Philippe (& Bram) - 

Firstly, I totally agree with you Phillip.  Vim uses an outdated
programming style that needs to change if we are to make real advances
without having a total code-bloat. It needs to be constructed to be
compatible with object concepts  - get rid of as many of the ugly
globals as possible.  

We need to be able to have it as an embedded object and we need it to
communicate with its host in a portable way.  
Eg. we don't really nead an OLE-VIM - all we need is an OLE module that
talks to vim via whatever RPC we choose to implement.

It would be great if we had one common API that we could plug whatever
scripting modules into we wanted.  We could always support
dynamic-linking for targets that allow it, and static-link those that
don't.

I have a feeling that Bram is not going to agree to doing any of this
just now, but I think it is a shame, and is one of the big reasons that
I find it difficult to work on Vim. 

HOWEVER, the commitment that Bram shows to Vim and to his Ugandan
project is astounding, and I respect him a lot for it and I can
understand why a change in direction could be rather scarey as far as a
time commitment goes.

I hope we do go somewhere with all this... Vim will be my favourite
editor for a while to come, but this is an opportunity to make it dazzle
the competition.

//.ichael G.



-----Original Message-----
From: Philippe FREMY [mailto:P.FREMY@OBERTHURCS.com] 
Sent: Tuesday, 5 November 2002 7:41 PM
To: vim-dev@vim.org
Cc: kvim-dev@freenux.org
Subject: Vim's future ?



	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/
[prev in list] [next in list] [prev in thread] [next in thread]