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

List:       vim-dev
Subject:    RE: [kvim-dev] RE: Vim's future ?
From:       Vince Negri <vnegri () asl-electronics ! co ! uk>
Date:       2002-11-13 10:42:29
[Download RAW message or body]

> Bram has not been willing to accept any change suggestion, so it is not
even
> time to start coding.

I think that's a slight caricature of Bram's position:

> > So if someone submit patches to improve [GUI separation], you will
accept them ?
> If they are good patches, yes.  If they are bad patches, no.

My experience in vim-dev is that it's a "show us the code" community. On
several occasions in the past there has been long discussion about 
such-and-such a feature, but nothing really happening until patches
appeared.

> > If you are so positive that a componentized vim would be useful, then go
> > ahead and start work on it. 

> This is probably what we are going to do.
> We probably won't start from the vim base because that would be too
painful.
> I regret it because vim is a stable code. Unfortunately, it appears to be
> very difficult to do something else than a vim application with it. 

But it does nevertheless serve a purpose - as your reference
implementation. Even if you don't use a single line of
Vim code, it would make sense for your component to be able
to read and understand at least some settings in .vimrc -
e.g. 'backspace', 'insertmode', ':map'. That will not
only make your vim-component more useable to existing
Vim users, but will mean that new users who start with
the vim component will have a smoother transition if
they find themselves having to use the console-mode vim
(i.e. because they trashed their XF86Config ;)


> I still think it would be an interesting addition for vim to separate it
> into a reusable vim-engine and a vim application front-end.

The problem is that it isn't an "addition", but a big
rework. Such a project requires not just volunteers, but
dedicated volunteers who won't leave the task half-finished
(which would represent a waste of effort.)

What seems more practical for us (the regular vim team) 
is to look into various ways to
approach the central problem of the blocking event loop, 
since this is a shared problem with anyone trying to 
create an OLE-embedded Vim in Win32. Yes, one can argue
that they are all "hacks" and not the ideal solution - 
but the end result might be good enough for some applications,
and moreover would likely be a compile-time option - i.e.
not endangering the stability of the codebase.

With respect to the separate issue of the layout of the
vim codebase, it's a matter of resources. Bram is 
concentrating on bugfixes at the moment; any re-arrangement
of the source code is of lower priority. Perhaps there needs
to be a "Vim janitor" scheme like the "kernel janitor" one,
where some people volunteer to submit (small) patches that improve
function documentation, consistent naming etc.

Vince




Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this 
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such 
privilege. Please advise the sender if you receive this e-mail by mistake.

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