Re: Vim's future ?
- * Philippe FREMY <P.FREMY@...> [021105 03:43]:
> -> it is very difficult to use vim as a gui component, without menuI don't disagree with your suggestions as they would apply to kvim, a
new gvim (using GTK2) and, for all I know, an improved win32 version.
As for the kpart however, do you really think vim is the best way to go?
Wouldn't vim (as you pointed out, no longer just an editor) be overkill
in kdevelop? I think it would make more sense for an embedded widget to
be much smaller and let the IDE handle things like make, diff,
I say this because I've spent alot of time looking at the code trying to
figure out a good GTK2 widget, so that I can :wq my way out of
everything. But after considering it and discussing it I realized all I
wanted to add to programs like bluefish (an html ide) was vi
keybindings, the other html specific functions are allready included.
Admitedly there are lots of programs were vim scripting would be nice,
but it would duplicate the programs builtin function and lead to a "more
than one way to do it" mess.
/|Brian Skahan | Towson University | bskahan@...|\
/ | Baltimore, MD US | \
\ |ICQ:165038477 AIM:bskahan77| /
\| p:4105308356| http://www.etria.com |cell@... |/
> > > A file is associated with a document. When you change a document, the
> > > is propageted to all the views. Yes, this means a lot of
> > > this is not a problem, I haven't seen performance issues.
> > >
> > How is this different from a vim buffer?
> Not much. The major difference though is that you can have multiple views
> one documents, and that a view may be a toplevel window. Vim does notBut it supports multiple views on the buffer.
> support multiple top-level windows at the moment.