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

List:       vim-dev
Subject:    RE: [kvim-dev] 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:

> > 
> > > > Would this problem be avoided if Vim wasn't embedded, but
> > > > floated free as another top-level window? 
> > > 
> > > Then vim is not embedded, and it doesn't make sense to have a
> > > component. You do not need components to have a vim editor running
> > > separately from KDEvelop.
> > 
> > It looks like we have a different view on what you call "integrated".
> > In my view the essential thing is that the editor and the other tools
> > communicate.  For example, the debugger tells the editor where
> > breakpoints are and the current PC position, so that the editor can
> > display glyphs at the right lines. 
> 
> This is not integration. This is communication or interoperability.

It's often called integration.  That's where the I in IDE comes from.

But let's not argue about names.

> > The editor offers the user the
> > possibility to place or delete breakpoints, this is reported to the
> > debugger.
> 
> You keep telling me that but setting breakpoints is exactly the thing I do
> _not_ want vim to do. I want vim to edit files, not to set breakpoints.
> KDevelop can set breakpoints without vim.

You are missing the point.  Try looking at a few IDEs and how you set a
breakpoint in a certain line in a source file.  It's always done in the
editor.  Visual Studio even has the function "run until cursor".  That's
the cursor in the editor.

You can also set breakpoints at the name of a function or in other ways,
you would not need the editor for that.  Then the debugger tells the
editor where the breakpoints are, so that glyps can be displayed at the
right position.

Defining the interface between an editor and debugger is one of the
essential parts of a modular IDE.  There are only a few implementations,
most IDEs come with one editor that can't be replaced.

> > Although the full integration would require both to work, many users
> > will be quite pleased if they just get the first part.  The Sun Workshop
> > interface does it this way and it works quite well.
> 
> On this, I have the same attitude that people critisising vi clones. Either
> you get full vi compatbility or you don't claim you are compatible with vi.
> The same goes for integration. 
> 
> I don't like half-finished projects and second class citizens. Either I get
> full integration or I get none. If someone is interested in half
> integration, he can take our code and do it.

You are very much looking into this with your personal preferences.
Don't try using your preferences as a world standard.  It won't work
very well.

Looking at it from the other side: If Kdevelop can only have an editor
in its own toplevel window and not as a separate one, I would call that
half-finished.  It's still missing an option that several people will
want to use.

I hope you see that there is no such thing as "the right way" if you are
making something new.  You can only give your personal opinion about
what you consider to be "the right way", it's not a world standard.

> Now that you understand what integrated means, do you see why the current
> vim makes this very difficult ? The best way for a component to work fine
> would be to have access directly to the vim's internal and take care of the
> gui in our own way and not in the way defined by ui.c .

Since you appear to know so well what you want to have, why don't you
start implementing it?

-- 
hundred-and-one symptoms of being an internet addict:
18. Your wife drapes a blond wig over your monitor to remind you of what she
    looks like.

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