[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-05 17:47:25
[Download RAW message or body]


Bram said:

> [I'm not replying to messages in sequence, sorry] 

As long as you are replying, this is ok for me.


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

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.

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

> The Sun Workshop interface is a good example of the second issue: 

I don't know this program.

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

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

> > To achieve what you suggest that we should do, use vim in a framework,
we
> > need a better separation in the vim components. This is why I have
posted a
> > suggestion for architectural changes.
> > 
> > What do you think about them ? Do you oppose them ? Do you think it is a
> > good idea ? you don't care ? We really need your feedback on this. As
far as
> > I know, you are the main vim developer and maintainer.
> 
> I disagree.  For the goals that I have seen mentioned it is not
> necessary to completely change the design of Vim.

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

> 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.
- 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
- syntax highlighting
- cursor (one per view makes sense)
- a status line
- a command line
- selection
- normal and insert mode
- search and replace
- 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.

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 ask for breaking anything, just isolating this from the rest. The
rendering of the view is not part of this API.

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 ?

> This is a _huge_ task, because Vim includes so
> many features that are correlated.  This will take several years to
> implement.

The only goal is to decorrelate them. This is something that will improve
vim's architecture and benefit all vim developers.

> Changing the design of a large application like Vim is a risky task.  It
> might results in a couple of years of work and ending up with an editor
> that still doesn't do everything it did before the redesign.  

I think I did not made myself clear. I don't want to break everything at
once. Small incremental changes until things are clearly isolated should be
possible, I hope.

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

> But my experience has learned that it is much better to redesign only bits
and pieces, one
> step at a time.  Not one big overhaul.

Do you think it is be doable, in a step by step manner, with my goals of a
core vim engine ?


> > I am very disappointed when you say that nobody has started integrated
vim
> > into a framework. We have managed to have vim in Konqueror, KDEvelop and
> > KMail. The patches are almost ready for a submission to this list.
> 
> As I explained above, I was talking about the interfacing with other
> applications.  I have not seen the patches you mention here, perhaps
> they do more than what I expected.  Let's see them!

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

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.

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.

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

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.

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.


	regards,

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