[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-12 21:20:19
[Download RAW message or body]


Philippe Fremy wrote:

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

This sounds like the same problem as running two Vim instances and
wanting to exchange info between them.  Not only registers and option
values, also file contents.  It's not easy to implement, but it should
be possible.

The alternative is using one Vim istance and separating the things to
support multiple toplevel windows.  That is probably a lot more
complicated.  Main advantage is that the trouble with inter-process
communication are avoided.

It seems we are repeatedly running into "good ideas" which will take a
lot of effort to implement.  We can keep on argueing about whether it's
needed, but so long is there is nobody to do the actual work it's quite
pointless.

I don't have to time for big changes, I'm already lagging behind in
fixing reported bugs.

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

Many people see threads as the only "clean" solution to handling tasks
that are inherently parallel.  Mapping multiple windows to multiple
threads is a very simple and logical solution.  Of course, the
implementation still has the handle all the nasty details involved with
inter-thread communication.  But that is not a reason to discard this
alternative right away.

> > - Run Vim in a separate process.
> 
> Already the case. Raises a bunch of issues too, because of long starting
> time and poor communication channel.

The long startup time has not been explained, don't discard an option
without knowing what the actual problem is.  Perhaps there is a simple
solution for it.

I don't know what you mean with "poor communication channel".  The
client-server stuff?  Well, then implement a better communication
channel.  I just received a first version of the Netbeans code, it uses
sockets.

> And I don't like adding workarounds after workarounds.

So long as the "clean" solution is too much work we can only try to find
quick&clever solutions that aren't too bad.

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

You know everything there is to know about Qt, right?

> > - Use setjmp() and longjmp().
> 
> I don't think it is possible with a vim component.

Why not?  These are generic C functions.

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

It's not a very nice solution, but if this is the key to make it work
without a complete redesign it should certainly not be discarded without
trying the solution and see what we end up with.

You appear to turn down many solutions just because you don't know what
it involves.  Doesn't the same apply to the solution of redesigning Vim
to how it handles input events?

> > Use a function call with remote_expr(), works in any state. 
> 
> Did not think about that. We could have a try.

Hopefully there are more things you didn't think about yet and we can
find a good solution for other problems.

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

Hmm, you appear not to be consistent: One moment you propose to make a
basic-Vim-engine to use in the component and here you want to use only
one Vim for everything.

I think it might be unavoidable that using Vim as a kpart component will
require different code than what is used for running Vim as a
stand-alone application.  If this extra code is selected at compile time
or with a command line argument can be decided later.  We first need to
find out what the extra code is.

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

Try reading the Vim documentation before you suggest radical
solutions...

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

Why should that be handled by the GUI code?  I know it's cleaner from
the viewpoint of a GUI programmer, but when you also have to make it
work on a console the choice is not so obvious.  Also remember my
remarks a few days ago about the command line and sticking to a Vi
look&feel.

> 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 code to handle maximizing is in the GUI specific code.  I know this
is not ideal.  It's tricky to make this work with all kinds of window
managers and GUIs.  Perhaps you can start with making this work properly
on all systems, properly separating the generic GUI code from the
system-specific GUI code.

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

No, the reason to do it this way is that the console version also needs
to work, and we want to share as much code as posible between the
console and the GUI.

Vim uses lower level GUI functions.  It doesn't use high level functions
such as "open a window with scrollbars".  Every GUI should allow
flexibility to position scrollbars as is needed.  Yes, that's more work
than using the high level functions.

The alternative is a complete redesign.  While making sure everything
still works for all GUI implementations.  You can imagine this is a huge
task, which I'm trying to avoid.  Solving small problems in each GUI has
been possible until now.

> > 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 think everybody would be relieved if he doesn't have to use those
extremely long X font names.  If Qt offers something simpler, please use
it.  Perhaps Qt even offers a function to translate the names forward
and backward?  It probably does, because it has to communicate with the
X server about these names.

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

Are you ging to make this vim-engine?

-- 
hundred-and-one symptoms of being an internet addict:
17. You turn on your intercom when leaving the room so you can hear if new
    e-mail arrives.

 ///  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]