Neovim: Rewriting & Modernizing The Vim Editor

[wizard69]

Where Vim really shines is repeated actions and text objects. If you want to delete the next 5 words, it's just 'd5w' (or '5dw'). If you want to delete the entire line, it's just 'dd'. Delete up to and including the next comma (useful for arguments in C), it's 'dt''. Changing the contents of a string is 'ci"', and so on and so forth. In most editors, the equivalent keystrokes are repetitive and take much longer.

I agree that the learning curve is steep. That said, everything described in the above paragraph is covered in vimtutor, which takes about half an hour to get through and is well worth it. Vim cheatsheets are also a great resource when you're new to it. I do think the default settings could be better though (e.g. "set nocompatible" should be enabled by default, otherwise you're missing out on 22 years of progress).

That learning curve is a huge problem though. The only reason I keep VIM or its variant around is because it runs everywhere. Honestly I was involved with Eclipse for a while but the bitch caused me some serious grief in the last couple of releases so I'm looking for a good editor / IDE.

I mention IDE because a good one is critical these days in my mind. Spinning up VIM is like going backwards in the slow lane.

Neovim is pushing Lua as a replacement to Vimscript, as it is apparently quite fast when JIT'd.
Take a look at vim-qt - I've found it works much better than GVim.

A good editor should have a well established programming language for scripting. I'm not sure Lua is the best choice for an editor ( haven't really thought about it ), but it gets very respectable results in other contexts. Frankly Lua is fast without JIT.

As to the variants of VIM, with one being better than the other, I guess that depends upon your perspective.

Rust looks like it could change that - it has the same low level focus as C, but a much nicer (optional) runtime and implicit memory management.

Honestly I see this project as a bit of a waste of time if it doesn't target something better than C. In this case I really believe that modern C++ would be the way to go.

That said, I suspect the main reason for writing Neovim in C is the desire to not fragment the codebase too much, so that there's the possibility of merging the changes back in.

That is a poor reason in my mind! If you want significantly better editing you have to break with the past. Otherwise why not contribute to VIM directly? A little C++ would go a long way to making supporting the various GUIs far easier. In fact I'd go so far as to suggest that a primary goal should be to refactor the program such that supporting the various GUIs is simple, well as simple as can be made.

In any event is see VIM currently as an editor of last resort. It might be just the nuts if you are a developer chained to a desk for endless hours everyday but beyond that it is trying even off putting.

[wizard69]

I would hope so too.

He's managed to raise over $30k on Bountysource, here's hoping that he does something good with all that money

The problem here is that I'm not convinced of the wisdom of writing (rewriting) VIM in C again. In fact I see it as a waste of time. It would be better to contribute to the current code base if sticking with C is mandatory. Otherwise it would make more sense to release ones self from the limitations of C and go with a languAge supporting modern methods.

https://www.bountysource.com/fundrai...e-21st-century

One possibility here would be a ViM lib that different GUIs could easily link to. Make the whole thing more modular while the redevelopment goes on.

[gilboa]

The problem here is that I'm not convinced of the wisdom of writing (rewriting) VIM in C again. In fact I see it as a waste of time. It would be better to contribute to the current code base if sticking with C is mandatory.

Without going into C vs. C++ debate (I use them both, though I personally prefer C) - keep in mind that rewriting VIM in CPP will more-or-less require a complete rewrite of more-or-less every single line of code (unless you plan to create an unmaintainable hybrid) - a huge task with few-if-any positive user-facing changes (and a lot of negative ones: stability, platform and compiler support changes, etc).
Rewriting specific problematic parts in C while keeping the old design is a far better choice.

- Gilboa

[wizard69]

Without going into C vs. C++ debate (I use them both, though I personally prefer C) - keep in mind that rewriting VIM in CPP will more-or-less require a complete rewrite of more-or-less every single line of code (unless you plan to create an unmaintainable hybrid) - a huge task with few-if-any positive user-facing changes (and a lot of negative ones: stability, platform and compiler support changes, etc).
Rewriting specific problematic parts in C while keeping the old design is a far better choice.

- Gilboa

Which in part is what I'm trying to get at, it makes more sense to contribute to the existing code base then to go off on a tangent. As it is now there is no assurance that anything done will be accepted back into VIMs code base. Thus the idea of wasted time. The VIM developers may welcome the changes or maybe not. If not you are on your own with a a forked project.

[isemenov]

How does donation funding work?

Good luck, patience and perseverance to the project author!

What I really don't understand is that on github, there are many people committing code to the project. The project leader only seems to have a few commits (although I can not comment on their importance, having no knowledge about the project at all.) Now who gets the money? Do I understand correctly that those people volunteer and help the leader for free, whereas he gets all the funds raised?

I know that it's not ethical to count others' money or wages, but I'm trying to understand, what is the mechanics behind this?

Thank you!

[Luke_Wolf]

Good luck, patience and perseverance to the project author!

What I really don't understand is that on github, there are many people committing code to the project. The project leader only seems to have a few commits (although I can not comment on their importance, having no knowledge about the project at all.) Now who gets the money? Do I understand correctly that those people volunteer and help the leader for free, whereas he gets all the funds raised?

I know that it's not ethical to count others' money or wages, but I'm trying to understand, what is the mechanics behind this?

Thank you!

Well, Presumably it all goes to the two developers who posted this project, and they are using it as funding for the ability to spend all of their time developing on it (i.e. they're working as contracted developers)

[isemenov]

But all the other 10+ developers, are they OK with helping 2 main authors make money with their free labor? How does this work?

[gilboa]

Which in part is what I'm trying to get at, it makes more sense to contribute to the existing code base then to go off on a tangent. As it is now there is no assurance that anything done will be accepted back into VIMs code base. Thus the idea of wasted time. The VIM developers may welcome the changes or maybe not. If not you are on your own with a a forked project.

True, but in the long run, if the code isn't accepted by upstream, the project owner may decided to fork VI(M) and his code is good enough, he may actually before the official VI(M)-like package installed by default in many distributions. (E.g. XFree86 vs. Xorg, LibreOffce vs. OO, etc)

- Gilboa