123 views
Skip to first unread message

Marc Weber

unread,
Apr 11, 2010, 11:08:04 AM4/11/10
to Bram Moolenaar, vim-announce, vim-dev, vim, vim-mac, vim-multibyte
In-reply-to: <201004111433....@masaka.moolenaar.net>
References: <201004111433....@masaka.moolenaar.net>


Hi Bram,

> I will try to include a few patches that have been pending for a while.
> I don't have much time available, thus I will only include things that
> take a few hours of my time. That basically means patches that are
> ready to be included.

This started bothering me for a long time. I appreciate every minute you
spend on Vim. The last updates adding completion features provide much
value to me.

If the Vim community started funding you would you consider adding some
more optional features to Vim? Maybe you know the code base best.

I think there are many Vim users in the world. If many Vim users just
spend some dollars it may be enough to pay some of your time which is
limited.

This mail is sent to all Vim mailing lists. So I suggest sending replies
to this thread to v...@vim.org only so that no cross posting
takes place.

Maybe its only my interest that Vim evolves. I don't know. That's why
I'm asking you and the community.

I'd like to see some async communication support. I started working on
it. But I don't have time left working on it. But I could spend some
money. This would allow users implement debugger integrations using
scripting languages.

Who else feels this way?

Marc Weber

Tux

unread,
Apr 11, 2010, 11:16:31 AM4/11/10
to vim...@googlegroups.com
Marc Weber schrob am 11.04.2010 17:08:

Maybe its only my interest that Vim evolves.

I second that.
(And, as the installer is about to drop support for ancient Windows versions, maybe it's time to break compatibility completely. One common rant about Vim is that it is compatible with OS no-one uses anymore anyway, so, probably..?)

Lech Lorens

unread,
Apr 16, 2010, 5:42:10 PM4/16/10
to Marc Weber, vim...@googlegroups.com
On 11-Apr-2010 Marc Weber <marco-...@gmx.de> wrote:
> In-reply-to: <201004111433....@masaka.moolenaar.net>
> References: <201004111433....@masaka.moolenaar.net>
>
>
> Hi Bram,
>
> > I will try to include a few patches that have been pending for a while.
> > I don't have much time available, thus I will only include things that
> > take a few hours of my time. That basically means patches that are
> > ready to be included.
>
> This started bothering me for a long time. I appreciate every minute you
> spend on Vim. The last updates adding completion features provide much
> value to me.
>
> If the Vim community started funding you would you consider adding some
> more optional features to Vim? Maybe you know the code base best.
>
> I think there are many Vim users in the world. If many Vim users just
> spend some dollars it may be enough to pay some of your time which is
> limited.
>
> This mail is sent to all Vim mailing lists. So I suggest sending replies
> to this thread to v...@vim.org only so that no cross posting
> takes place.
>
> Maybe its only my interest that Vim evolves. I don't know. That's why
> I'm asking you and the community.

I can assure you it's not only your interest that Vim evolves. And
I would too be happy to sponsor Vim development. This model, however,
has already been tested and it has failed.

> I'd like to see some async communication support. I started working on
> it. But I don't have time left working on it. But I could spend some
> money. This would allow users implement debugger integrations using
> scripting languages.
>
> Who else feels this way?

Instead of asking Bram to try to go back to the old development model
which failed, you might try getting some interest on the vim-dev list.
Describe what you would like to achieve, what you have done, what you
have problems with. If someone else is interested you might get some
help and maybe at some point get your features implemented.

--
Cheers,
Lech

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en

mobi phil

unread,
Apr 16, 2010, 5:55:51 PM4/16/10
to vim...@googlegroups.com, Marc Weber



Instead of asking Bram to try to go back to the old development model
which failed, you might try getting some interest on the vim-dev list.
Describe what you would like to achieve, what you have done, what you
have problems with. If someone else is interested you might get some
help and maybe at some point get your features implemented.

--
Cheers,
Lech

I would be happy to contribute to vim code. I failed several times due to the complexity of the code. I am sure everybody would profit if the code would be re-factored a bit. This was discussed several time, but unfortunately most of the users/developers see almost zero interest in that. One should just define some interfaces for buffer, window, etc. and then it would be much easier to build on top of that. 99% of the scripts could be reused, lot of them could be improved by writing faster C code.  Myself I started to write some models for the buffer. The windowing system should work sthg. like links2 does, where different gui system would implement a driver for windowing etc. Porting would be much easier to new gui systems etc. etc. I am sure I will not hurt anybody, especially Bram, but vi/vim and ideas behind is/are a global inheritance.

Question: is anybody interested in that?




--
rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com

Lech Lorens

unread,
Apr 17, 2010, 9:36:41 AM4/17/10
to mobi phil, vim...@googlegroups.com
On 16-Apr-2010 mobi phil <mo...@mobiphil.com> wrote:
> I would be happy to contribute to vim code. I failed several times due to
> the complexity of the code. I am sure everybody would profit if the code
> would be re-factored a bit. This was discussed several time, but
> unfortunately most of the users/developers see almost zero interest in that.
> One should just define some interfaces for buffer, window, etc. and then it
> would be much easier to build on top of that. 99% of the scripts could be
> reused, lot of them could be improved by writing faster C code. Myself I
> started to write some models for the buffer. The windowing system should
> work sthg. like links2 does, where different gui system would implement a
> driver for windowing etc. Porting would be much easier to new gui systems
> etc. etc. I am sure I will not hurt anybody, especially Bram, but vi/vim and
> ideas behind is/are a global inheritance.
>
> Question: is anybody interested in that?

Interested in what? You haven't proposed any concrete actions or steps.
Asking people to rewrite Vim - admittedly a concrete step - without
giving a good reason is not something feasible. Especially given the
fact that you have absolutely no guarantee that you would end up with
code that would be better in any aspect than the one you have now.
Sorry.

--
Cheers,
Lech

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en

mobi phil

unread,
Apr 17, 2010, 10:03:47 AM4/17/10
to mobi phil, vim...@googlegroups.com

Interested in what?

in writing new vi, but a vi that is not only 1 person project but really community project.
 
You haven't proposed any concrete actions or steps.
concrete stepso and actions were proposed. But myself I would not invest too much time, unless there is audience and interest. If the spiral works then things come from self.

so concrete steps was proposed in my previous email. Define interfaces. See if everybody thinks the same etc. etc.

 
Asking people to rewrite Vim - admittedly a concrete step - without
giving a good reason is not something feasible.
Good reason was also mentioned. Make the code 100 times more flexible maintainable, add regression tests etc. etc.

 
Especially given the
fact that you have absolutely no guarantee that you would end up with
code that would be better in any aspect than the one you have now.
Sorry.
 
The core is not necessarily big. Indeed it is not 1 man project. But at least 10 peoples contribution would make it for sure.




--
rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com

Reply all
Reply to author
Forward
0 new messages