[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-12 13:08:46
[Download RAW message or body]


> > 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 mean two KDevelops ? I don't know if it deals with it.

> You wouldn't want to make a change in one window and another
> change in a second window for the same file.

A file is associated with a document. When you change a document, the change
is propageted to all the views. Yes, this means a lot of communication. But
this is not a problem, I haven't seen performance issues.

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

Indeed. We need to add more and more hacks to make things nice. And wich
each hack, we discover new problems. I am sick of this and I would like to
have a cleaner base: a vim engine that we could control the way we want it.


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

Makes it complicated and doesn't fix all the other problems we have. They
will even be worse because we will have to think about parallelising in
addition.

> - Run Vim in a separate process.

Already the case. Raises a bunch of issues too, because of long starting
time and poor communication channel. And I don't like adding workarounds
after workarounds.

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

Not possible in a component vim.

> - Use setjmp() and longjmp().

I don't think it is possible with a vim component.

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

Yeah, that and probably many other tricky things. I am no expert in setjmp
usage but I am sure there are many pitfalls.

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

Did not think about that. We could have a try.

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

We wanted to minimize the number of things the user has to install to get
the vim component working. So we use the user's current vim. Another reason
is that the user expects its component to read its script files.

The delay is due to X and vim initialisation.

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

Does vim accepts commands from its stdin ? I wasn't aware of that.

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

No it isn't. Another example is the vertical splitting. For gui client,
vertical splitting should be handled by the GUI code, not by vim. I am sure
I can find other examples.

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

It is fine for vim to choose the number of lines of columns it wants to
display. But it should not choose more. Not the placement pixel-wise of the
scrollbar. Not the total size of vim. And not the size of the vim maximised
window calculated from the size of desktop.

The reason vim gui code is not right is that the first gui developed was
probably the X one. X being very raw, you have assumed that every other gui
will have a poor interface and you need to control it tightly. However, with
today's gui toolkit, this is wrong. The solution is to change slightly the
GUI api to make them more high-level, and keep the low-level stuff (like
manual vim maximising) inside each gui.

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

Because the user may be using the Gtk-vim and the KDE component. He expects
to have the same fonts in both vims.


> I'm indeed getting the impression that you got discouraged because of
> the large number of problems.

Indeed.

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

Having a vim-engine without specific gui-code where we would be able to plug
our own gui interface is a nice solution. I am _sure_ about this. Yes, we
would have to deal with problems but that would be real issues and not
workaround after workarounds.

	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]