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

List:       vim-dev
Subject:    Re: [vimdev] Re: Vim's future ?
From:       "Brett Pershing Stahlman" <brett.stahlman () dynetics ! com>
Date:       2002-11-07 20:13:31
[Download RAW message or body]

----- Original Message -----
From: Brett Pershing Stahlman <brett.stahlman@dynetics.com>
To: Michael Geddes <mgeddes@au.mediacommand.com>; Bram Moolenaar
<Bram@moolenaar.net>
Cc: Vim Dev <Vim-dev@vim.org>
Sent: Thursday, November 07, 2002 1:40 PM
Subject: Re: [vimdev] Re: Vim's future ?


>
> ----- Original Message -----
> From: Bram Moolenaar <Bram@moolenaar.net>
> To: Michael Geddes <mgeddes@au.mediacommand.com>
> Cc: Vim Dev <Vim-dev@vim.org>
> Sent: Thursday, November 07, 2002 4:03 AM
> Subject: RE: [vimdev] Re: Vim's future ?
>
>
> >
> > Michael Geddes wrote:
> >
> > > It's not Qt (I'm assuming) in itself that is the problem - it's making
> > > vim into an embedded control.  The same problems would become apparent
> > > if we were to make vim an ActiveX control under win32 (I'm not talking
> > > about using at as an .exe COM server here).
> > >
> > > So, it's not making it a stand-alone GUI that is the problem - it's
> > > embedding it in another GUI's event loop that is the problem - and
this
> > > is effectively what an ActiveX control does - and from what has been
> > > said, also the same for a Qt plugin (which makes sense).
>
> > > I'm not totally unsympathetic to your views on how the code should be
> > > organised - but coding methods have developed a long way, and they add
> > > exciting new dimensions to the possibilities for User-interfaces - and
> > > all/most of us on this list would like to see vim amongst the
> > > possibilities.. without taking away its usefulness as a
> > > command-line/terminal editor.
> >
> > Best would be to reimplement it from scratch, so that you can use the
> > latest design ideas.  Feel free to give it a go! :-)
>
> From everything I've read on this thread, it seems to me that what is
wanted
> is, in effect, a Vim "emulator", albeit with support for registers, marks,
> and perhaps even eval-related stuff (stuff you wouldn't ordinarily get in
> the type of Vi emulation that's provided in some IDEs), which could be
> packaged into a component for use via OLE, COM interfaces, or whatever. In
> other words, just a Vim "engine", as Philippe put it. I believe this is
> something that would be wonderful to have; however, I think trying to
modify
> the current source code to do it would be insane. The current Vim was
never
> designed with this paradigm in mind; hence, it would probably be easier to
t
> ake from the current Vim a sort of "Vim standard" for the (text editing
> portion only), and develop the new source code with a completely different
> sort of implementation, but one which would be compatible with the
standard;
> i.e., user-commands would be the same, but much of the internals would be
> structured differently.
>
> Certainly, this would be a big task, but since it would be completely
> separate from "Vim the Application", it would not affect current Vim users
> in any way. Anyways, it wouldn't be as big a task as the original Vim
> development, because a lot of what Vim the Application does would be
handled
> in the IDE using the Vim engine component, and as such, would be
completely
> unnecessary in the component code. Since most IDEs in which Vim the
> component would be used would have their own syntax highlighting, this
> portion of Vim would probably not be necessary either.
>
> I have used Vim for several years now, and love it. The major problem I
have
> with it, however, is that, although there are syntax files for just about
> every language on the planet, many modern programming languages make it
> nearly impossible (or at least, somewhat awkward) to develop source code
> apart from the IDE. I mean, I develop in MS Visual C++ a lot, and although
I
> use the Project plugin very effectively on my project (which contains
around
> 200 source files) for making minor source code modifications now that the
> application is basically stable, if I need to add code that is GUI or
> message-map intensive, it's much easier to go back into the VC6 IDE to do
> it, since editing resource scripts and message map macros by hand would be
> very tedious. I realize there's an OLE Vim that was designed for this, but
> in the past, I've had problems with the stability of this interface, and
> besides, that's only for Visual C++. What about VB, Java, etc...
>
> Anyways, that's my 2 cents.
>
Wow! Scratch what I said about most Vi emulators embedded in other IDEs not
having support for things like registers. I'm playing around with a trial
copy of Visual SlickEdit, and was pretty amazed at the Vim-like feel of it's
Vi emulator. For example, you can enter command-line commands. You can yank
to named registers. You have unlimited undo (haven't found redo yet), even
for cursor movement commands. It even has the little column of '~' on the
left edge of the buffer where no lines of text exist! (to make a Vim user
really feel at home...) Unfortunately, it doesn't look like Vim-specific
commands (e.g., "let") are supported, but it appears to have some other
macro language. I'll have to play around with it some more to see how that
works...

> Brett S.
>
>
>


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