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

List:       vim-dev
Subject:    RE: Vim's future ?
From:       Philippe FREMY <P.FREMY () OBERTHURCS ! com>
Date:       2002-11-06 13:34:04
[Download RAW message or body]


Update on what I previously said.

In my first mail, I suggested something that can be seen as a drastic change
to vim, in order to make it easy for us to have a good component.

After the discussion we have had, I think things needs to be clarified.

The change I suggested can be seen as drastic. However, Bram pointed out
that almost every abstraction that these change want to provide are already
present in vim. Thus my proposition should not be seen as a suggestion for
drastic changes, but a suggestion to isolate more clearly some features of
vim, so that we can acutally use them in our own way.

Bram is rightfully reluctant to perform any change to vim, major or minor,
without good reasons and proof of the interest it provides.

I'll try to present clear arguments.

It seems that most people here have agreed that having vim as a component,
in KDE and in other framework, is a desirable thing. We have been coding for
a few years on the vim KDE component and our conclusion is that while it is
possible to make some kind of vim component, the current vim code doesn't
permit us to make a full-blown component.

What are the problems ? First, let's have a look at what a component is. For
KDE, a component is a widget that provides some services. A component gets
embedded into its host application. The component may wish to provide its
own menu and toolbar entrie in the host application. In KDE, components are
implemented using Qt and shared libraries. This means that the component
must be able to provide a QWidget that the host appliation can use. The
shared libraries means that the component can not take over the event loop
of the application. It should only reacts to events when they occur, and
return when the processing of the event has been finished.

More doc on KDE components:
http://developer.kde.org/documentation/tutorials/kparts/index.html

For vim, we have three components in mind: read-only, read-write and editor
component. Read only and read-write
(http://developer.kde.org/documentation/library/3.0-api/classref/kparts/KPar
ts__ReadOnlyPart.html and
http://developer.kde.org/documentation/library/3.0-api/classref/kparts/KPart
s__ReadWritePart.html ) components are very easy to provide because the API
is minimal. Such a component only needs to be able to open a file and write
it. The current kvim does that very well. These components are used in
Konqueror to display file contents. Probably also in kmail and in a few
other places. Implementing this with the current vim architecture wasn't
much trouble.

The most interesting component for KDE is the editor component (doc:
http://developer.kde.org/documentation/library/3.0-api/classref/interfaces/i
ndex.html ). The component has more interfaces to provide, but it can then
be used by really any application. Any complex task required by a KDE
application for an editor can be achieved with this interface. If vim is
able to be used here, there is no place in KDE where we won't be able to use
it.

As Bram noted, KDevelop interfaces are not there. I don't think all editor
interfaces for KDevelop are ready yet. Even if they are, I don't think they
will be put in KDE. They will more probably be put inside KDevelop. KDevelop
is also moving from an old codebase (KDevelop) to a new one (Gideon) where
everything is modular, defined with a clear interface, thus can be changed.
Anyway, if we manage to implement the KDE editor interface, implementing the
KDevelop one should not be much work.

What is needed for us for a good vim component ? If you look at the
interfaces, you see that there is one for a document and one for a view. KDE
is object oriented and expects to be able to create as many views (QWidget)
on an abstracted document as it needs. There is a class Editor that
accomodates the fact that one may wish to have only one class per document
view. However, you may have multiple documents for the same component.

I don't know in which extent the editor interface is used. Is everything
needed and used ? I think that yes. Anyway, it would be good to be able to
have all this implemented in the vim component.

KDevelop uses a MDI architecture, with possibly multiple views on the same
document, and multiple document. I have tried to ask them a simplification
of their requirements for an editor component, because it was not possible
to do it with the current vim. Their answer was basically that doc/view is a
common architecture of editors, many editors have it and can integrate in
KDEvelop. They see no reason to change their code only because vim can not
accomodate a modern architecture.

So, one problem.

What are our others problems ?

- the blocking event loop: I said a component must be called and should
return. Vim don't see it that way. It takes over the control of the event
loop and calls sometimes gui_wait_for_chars(). In kvim the application, we
can manage this by calling Qt::processEvents() inside gui_wait_for_chars().
But this is less than optimal. If you don't do it very carefully, vim will
take 100% cpu while doing nothing! Even if you manage to avoid that, the
result is very slow. I am pretty sure kvim is a lot slower than the terminal
vim because of this. For you, Bram, this looks as an acceptable solution
because it allow not to change too much of the console code. For us, it is
crippling the gui. The fact that it work doesn't mean that it is a good
solution. This is crippling other gui too, as all gui work with an event
loop.

This works for the kvim application, but it is not possible to use such a
trick with the kpart, because in a component, we don't have full control of
the loop. So turning vim as a component (shared library) was not possible.

The only way we could solve that problem was by running vim in another
process, and communicate remotely with it. It has the following drawbacks:

1. forking is an expensive system call

2. we must use a slow communication channel to exchange with vim. We can use
DCOP or the client/server stuff of kvim. DCOP is fine. The client/server
stuff is rather poor. It provides no feedback of whether the action executed
was successful or not. Moreover, we can only issue user commands. This will
conflict with the user. For example, if I want to move the cursor at the end
of the buffer, I can issue a 'G'. But what if the user is in insert mode ?
Then I must issue 'ESC G'. But if the user is already in normal mode, he
will hear a beep. If the user was in insert mode, I should return the user
to insert mode ? Then I must fetch the current mode (I don't remember but
there is a function for that), turn into normal mode, perform my action and
return to the mode the user was in. This adds a lot of overhead for very
simple actions. If I issue a command that need command mode, the user will
see that its command history has changed and wonder why.

3. In our fork, we start a vim we have no control over. Our hope was to be
able to embed our own vim, that would have minimal settings and would show
up very fast. This is not possible, we start a vim that the user has set,
which takes sometime a long time to start. Embedding the external X-Window
is a costly operation which adds to the delay.

4. Races: we can not communicate with the vim using client/server stuff
until it is started. However, it does not notify us when it is ready to
receive client/server commands. My initial attempt would drop the first
commands I sent to the vim server. Waiting for the vim window to be mapped
was not enough, because the vim server still was not ready to receive
client/server commands. So Mickael managed to do it but it was again tricky.
There is a queue to store the first commands that can not be sent.

5. Asynchronous calls: to communicate with the vim server, we would fork
(time penalty again) to launch a vim to send the command. Initially, to
speed things up, I would not wait for the process to finish. But the result
was sometimes mixed commands, so I had to make this an expensive synchronous
call. 

6. focus: we have discovored focus bugs when embedding an external X-Window
(gvim) into our component widget. The bugs are related to the X11 embedding
mechanism, so are tough to solve.

There are more drawbacks but I don't remember them all.

- tight control over gui: vim wants to control the gui very precisely, in
places where it does not make sense. For example this is a problem when
resizing a window. Resizing the window sends a resize event to the text
frame and to the scrollbar. The resize event to the text frame is
transmitted to vim which decides that the text frame needs to be resized and
resizes it again. I am not sure but I think it tries to resize the scrollbar
too. Vim also gives pixel dimensions for everything and tries to place
widget himself, which conflicts with Qt's automatic widget stacking features
and does not work well with our windows. By assuming vim knows better than
us what the gui should do, it creates lot of problems for us. The current UI
interface is probably right for X11 and console. It conflicts however with
modern toolkits such as Gtk and Qt.

- incompatible font names: KDE can use anti-aliased fonts. So everybody has
been trying to get kvim with anti-aliased fonts. Unfortunately, Qt and vim
don't encode font names the same way. So it was not possible to select a
font using KDE's font selection dialog and store it in the vim configuratino
file. I don't think we should blame Qt or vim, but this is a problem.

- it is not possible to provide an interface for the doc/view editor
component, because vim has only the concept of one window application.

I think this was the biggest problems. When facing all this, I just stopped
working on kvim. Hopefully, Mickael came later and fixed bugs after bugs. I
thank him thousand times to have finished the kvim and vim component. He did
the dirty work of working around all those problems.

Now, you have a better overview of our problems. It is time to think about
potentials solutions.

I am running out of time for today, so I'll continue this tomorrow. I hope
this gives a better understanding of our problematic.

	regards,

	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]