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

List:       vim-dev
Subject:    RE: Vim's future ?
From:       Bram Moolenaar <Bram () moolenaar ! net>
Date:       2002-11-06 23:08:31
[Download RAW message or body]


Philippe Fremy wrote:

> I'll try to present clear arguments.

I'm glad you do!

> 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.

How does KDevelop avoid that a user has two different editors on the
same file?  You wouldn't want to make a change in one window and another
change in a second window for the same file.

Possible solutions:
- Just allow it and tell the user he should not edit the same file
  twice.
- Make sure changes can be done in only one window, the others are
  read-only.
- Distribute changes from one editor to another editing the same file.
  The defined KDE interfaces appear to have something for this already.
- Make it possible for one Vim to have two KDE windows.

None of them is really attactive, this requires research to find the
least-bad solution.

> - 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.

Possible solutions:
- Use threads, run Vim in a separate thread.
- Run Vim in a separate process.
- Use the right Qt function to wait for the next event to be used by
  Vim.  I would be surprised if it doesn't exist, since the normal GUI
  loop would do the same thing.
- Use setjmp() and longjmp().

The last one sounds like a reasonable solution, but it requires
verifying there is no catch.

> 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.

Any kind of communication would work.  The Sun Workshop interface uses
pipes.  Sockets would work the same way (setting them up is more work).

> 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.

Use a function call with remote_expr(), works in any state.  Or prepend
CTRL-\ CTRL-N and accept that you don't go back to Insert mode (that
might be what you wanted anyway).

> 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.

Don't understand this remark, you can run exactly the Vim you want to
run.  Call it "vim-kde-component" or whatever.  Or give it a series of
command line arguments.

> 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.

Using a pipe would be a lot simpler if you are starting Vim yourself.
This is what Sun Workshop uses, works just fine.

[...]

> 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.

You use resizing as an example, but I would think it's actually the only
problem of this kind.  It is not easy to figure out and make it work,
but it should be possible (either by making the kvim-specific code
smarter or by modifying the size handling inside Vim).  If you disable
the possibility for Vim to set it's own size (":set lines=88") you have
probably reduced the problem considerably.

> - 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.

Well, just switch to using Qt font names and implement this in Vim.  The
names are used only in very few spots of the code.  The X11 and Win32
font names are completely different and this works, so why would Qt font
names be 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.

You need to start a new Vim for every KDE window.  That would cause a
few problems that need to be solved.

> 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.

I'm indeed getting the impression that you got discouraged because of
the large number of problems.  You quickly get the idea that a
completely different approach would be the solution.  It's easy to
ignore that this new solution also has its problems, since you don't see
them yet.  From my point of view the problems are solvable and there is
no need to go into a completely different approach.

-- 
ARTHUR:    Be quiet!  I order you to shut up.
OLD WOMAN: Order, eh -- who does he think he is?
ARTHUR:    I am your king!
OLD WOMAN: Well, I didn't vote for you.
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 ///  Bram Moolenaar -- Bram@moolenaar.net -- http://www.moolenaar.net  \\\
///          Creator of Vim - Vi IMproved -- http://www.vim.org          \\\
\\\           Project leader for A-A-P -- http://www.a-a-p.org           ///
 \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
[prev in list] [next in list] [prev in thread] [next in thread]