[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 10:55:00
[Download RAW message or body]


Philippe Fremy wrote:

Before replying to individual blocks of text, let me say that using Vim
as a component is something I would like to support.  What we are
discussing here is _how_ it should be done.  Overall my point is that it
only requires minor changes, while Philippe is trying to convince me
that drastic changes are to be done.  I'm challenging Philippe to show
me why these drastic changes are necessary.

> > I thought you have been working on making Vim work together with other
> > KDE applications, as in Vim as a widget.  I had not heard about
> > interfacing Vim with a debugger, HTML viewer, cross referencer, project
> > browser or something like that.
> 
> You are right in that we almost only provide a widget. But this means a lot
> more than what you think. Our work had been to provide vim as a widget to
> KDE, but more important, as a KDE editor component. KDE is fully
> componentised. It defines the services it needs to have an editor. Then it
> uses this editor components in all applications that needs it.
> 
> Vim is used in kmail if we ask for it. Vim is used in Konqueror as the a
> viewer if we set the vim component as preferred viewer for the mimetypes.
> Vim is used in every app that requests text edition if you set the vim kpart
> as prefereed editor component.
> 
> The editor component can implement many interfaces (see
> http://developer.kde.org/documentation/library/3.0-api/classref/interfaces/i
> ndex.html): Edit, Cursor, Undo, Selection, Print, Completion, ... An
> application usually request an editor component that is able to support some
> of these interfaces.

Thanks for the URL, this is useful.  It's a pity that most of these
interfaces are not documented, it's not clear how they are to be used.
Perhaps this is written down somewhere else?
They appear to be quite low level anyway.  Would still be a lot of work
to do something with this.  It also explains why it would be difficult
to implement them for Vim.

> Mickael has already implemented a few of them for kvim. The more we get, the
> more usage we can have for the component (and the more vim rocks!).
> 
> There are two promising projects where vim would be great. KDevelop and
> Kate. KDevelop is a full blown IDE. Kate is an editor framework. For both of
> them, the feature you are thinking of (breakpoints, debugger, ...) are
> implemented outside of the editor component, in KDevelop and Kate. The
> required editor component is dumb in this case, but the result is still a
> powerful application.

I don't see an interface defined that would be useful for a debugger,
such as displaying breakpoints and evaluating variable values.  How does
Kdevelop use the editor component to do this then?

> > Thus there are two separate issues:
> > 1. Making Vim work in a subwindow as part of a larger application.
> > 2. Making Vim interface with other applications.
> 
> In KDE, providing a vim component with all the texteditor interfaces solves
> both issues.

You still have to implement both issues: Make the event handling, menus,
etc. work and implement each interface.

> > The Sun Workshop interface is a good example of the second issue: 
> 
> I don't know this program.

Didn't I suggest to take a look at this before?  I'm quite sure I did.
The Sun Workshop interface is the most complete integration between Vim
and a debugger.  It includes setting breakpoints (displayed with a
glyph), popup windows to show the value of a variable, stepping through
the code with menu commands in Vim and much more.  It actually works,
but since Sun Workshop is commercial, you probably can only look at the
code.

> > Tell Vim to put a breakpoint somewhere, let Vim tell the debugger to
> > step to the next command.  This is two-way communication.
> 
> You are asking a too intelligent thing. In many IDE, setting a breakpoint is
> only a red dot in the left margin of the editor. Nothing that has to be
> handled in the editor directly. The only thing the framework needs to know
> is if the editor modifies the line count, to adjust the place of the red
> dot.

Fortunately, Vim can already display signs, as they are called.  And the
editor must handle this, since it affects displaying, undo/redo,
wrapping lines, folds and much more.  Would be very complicated (and
inefficient) to handle this outside of the editor.  The editor would
still have to tell where the glyph is to be positioned, thus it might as
well do it right away.

> > When combining the two you have some kind of IDE, depending on what
> > things you put together.
> 
> We have a problem of abstraction level. You think of vim-the-editor at a
> higher level than what we need. Your editor lets you perform many actions
> that are not directly related to editing: browsing files, diffing files,
> launching make, setting breakpoint. For me this is an enhanced editor. We
> (the component team) need a very simple thing: something that display texts,
> has a cursor and allow to modify the text. 
> 
> All the additional stuff is handled in another part of the appliation. For
> example, Kate is an editor framework. It lets you organise files into
> projects, browse file, search through files, grep with regular expression,
> use CVS. None of these feature are part of the editor component.

These are choices to make.  My experience is that displaying text is
very complicated, and trying to make an interface to influence how it
works is difficult.  Thus anything that is related to displaying text
should be done by the editor.  This includes handling filler lines (for
diff mode), folding and wrapping lines.  Try to design an interface that
handles displaying a dot at a breakpoint, while the editor wraps lines
differently because the winow width changed.  It's possible, but lots of
work.  These things are really better done inside the editor.

Again, have a look at the workshop interface.  This shows something that
actually works.

> The goal is to isolate components inside vim. I hope it is possible to do it
> without completely break the design of vim. 

No, the goal is to make a good editor.  What we do with components is a
way to get there.  Design is never a goal (unless you are teaching
computer architecture).

> > Instead of arguing about vague things, let's please stick to clear
> > examples.  Otherwise we don't know what we are talking about.
> 
> Okay, I think for our needs, we need a vim engine without gui but with:
> - the notion of document with an interface -> edit this text, insert this
> line, remove that word.

Done, Vim has plenty of commands for that.

> - the notion of view -> render this portion of this document, tell me
> when this document change, tell me where the cursor is, tell me to
> highlight text

All possible already.

> - syntax highlighting

Yep.

> - cursor (one per view makes sense)
> - a status line
> - a command line
> - selection
> - normal and insert mode
> - search and replace

Ehm, these are low level features, I don't see the relation with design.

> - vi-compatible keys for moving
> - vim engine features like abbreviations, completion, vimrc, registers, ...
> Those are not completely needed but if we don't provide them, vim power
> users will feel restricted.

All this is already present.

> If you can isolate this from vim into a separate directory, with a clear
> API, we will be able to use it into a powerful component.

I don't see what a separate directory has to do with this.  The Vim
commands are the API, clearly defined and stable.

> I don't ask for breaking anything, just isolating this from the rest. The
> rendering of the view is not part of this API.

How can you edit text without rendering it?  Scrolling and cursor
movement all are related to editing, thus it must be part of the whole.

> I hope it doesn't sound too difficult. Vim already has the notion of view,
> as you said. So making it a full abstraction should not be that hard ?

In fact, I think all of what you mention is already there.  So what's
the real issue you were trying to get to?

> > And what will the average Vim user gain in the redesign? 
> 
> Not much. The clearer architecture will provide room for less bugs and
> features easier to implement. However, the average vim users that like IDE
> will gain a lot. He will be able to use its favourite editor in its
> favourite IDE. The KDE/vim user will finally see a reconciliation between
> its separated loved projects.

I'm afraid I still haven't heard the reason a redesign will make it
easier for Vim to be used as a component.  Please be very clear about
this.

[bits and pieces removed]

> As I explained above, you won't see much in the patch themselves. Moreover,
> the component code is separate from the kvim code. You can peek at
> http://kdewebcvs.pandmservices.com/cgi-bin/cvsweb.cgi/kdeextragear-1/vimpart
> /src/

I did have a look at the code, but it's difficult to see what changed.
The patch includes many Vim 6.1 patches.  Clearly a few files are added
for the KDE specific code.  But the interesting bits for this discussion
are in the details, these are hard to find.  You will have to point them
out.

> > I really don't see the problem yet that can't be solved with small
> > changes.  Please be specific about what would stop Vim being integrated
> > with something else.
> 
> To have a clean component, we must be able to:
> 1. control vim: open this file, edit that text, insert that line, move
> cursor here, scroll to that line, select paragraph, ...
> 2. query vim: current line ? cursor position ? current buffer ? current
> selection ?
> 3. have our own display that is notified of text changes

What is "our display"?  Why does it need to know about text changes?

> 1. and 2. are achievable with the current client/server stuff, although the
> interface could be greatly improved. I know Mickael implemented DCOP access
> (the KDE communication protocol) inside kvim, so that we can use a richer
> transport protocol.

OK.

> 3. is done with a full vim window now. It would be great to have full
> control on how it is done. This is what is stopping us now.

What is "full control"?

> Mickael, the current maintainer and developer of kvim could probably say
> more about this than me.

I'm apparently missing something here, please explain what exactly is
stopping the use of Vim as a component in KDE.

> With aap, you want to make vim more powerful. The only thing we want is a
> simpler vim. The goal are not exclusive at all. In fact, a simpler vim could
> be useful for aap too.

With A-A-P I want to define interfaces between tools.  Vim is only one
of the tools.  It's really not much different from what you are doing
for KDE, but A-A-P should work on any platform (and will probably not
look as nice as KDE) and work with many tools (not just KDE components).

> As a sidenot, if the goal if aap is really to have a powerful graphical
> editor framework, you should think about joining a project like Kate and
> help us provide better vim integration. This would be easier than
> redeveloping everything from scratch.

Does Kate run on MS-Windows and Mac OS?  Can I install it without
dragging in Megabytes worth of libraries?

I certainly don't want to start from scratch, but it's very difficult to
find something that meets my goals.  Netbeans comes close, but suffers
from being too large and slow (it's implemented in Java, thus
portability is OK).  I've been thinking about IDLE (a nice small Python
IDE), but it uses tkinter, which many people object against.  Still have
to do more research into the alternatives.  I'll certainly look at
Kdevelop again.

-- 
CART DRIVER: Bring out your dead!
   There are legs stick out of windows and doors.  Two MEN are fighting in the
   mud - covered from head to foot in it.  Another MAN is on his hands in
   knees shovelling mud into his mouth.  We just catch sight of a MAN falling
   into a well.
                 "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]