Vim is moving to GitHub | Hacker News Reader

Vim is moving to GitHub

groups.google.com

43 pointsIuz17 comments

Wise decision, but I feel like with momentum that neovim has, it's gonna be hard to get any meaningful contributions. Certainly better than having it off github.

I don't know, neovim has its problems too. And seeing as it's not even stable yet, let's not put the cart ahead of the horses. It will be exciting to see the direction both projects take over the coming years.

Which issues have you encountered with neovim? You could use it daily and wouldn't notice too many issues. It's relatively stable for an alpha version.

This if the first time I have heard of neovim. Can you elaborate a bit more on the pros and cons ?

The neovim site had this:

Is it ready to download and run now with all the features?

No. Although some features are a work in progress, Neovim isn't at a stable point. Using Neovim should be done with caution as things may change.

Neovim was started by a guy called tarruda who (if I recall correctly), after trying several times to introduce background processes to vim, was rejected, so he decided to fork vim and try to work on that alone (he wrote a post here in HN which helped neovim take off).

The main advantages of neovim are the possibility to embed it into an IDE (basically be able to use vim inside any IDE without having to create a plugin emulating it), the ability to extend vim in any language, a cleaner code base, background processes (running grep locks vim), and a few other things.

It has some good momentum. There are some contributions and definitely a lot of discussion. It has also removed a lot of cruft from the code base. It's way cleaner (with the downside of only supporting Windows/Mac/Linux/BSD, but it's a great trade) and I guess it will help to incrase community contributions, because people tend to dislike mailing lists, especially those that do not have much experience contributing to open source software.

I think that's just the usual "not 1.0 yet". IIUC the goal of cleaning up the C-code is not yet complete nor is the "new plugin architecture" (but vim plugins work). I find it very stable and everything I previously used in vim works fine.

Their issue close rate is impressive, as well as the long list of RFCs in the pull-requests queue, a large number of which are cleaning code and tests.

pros: it's basically the same as vim. future pro: cleaner code, more stabile/better perf, new package ecosystem. cons: it's not vim. You can update more frequently. If you have a really old machine it won't run neovim (but will almost certainly be "supported" by vim).

You didn't cite the biggest advantages of neovim: for example, the possibility to embed neovim inside IDEs or background processes. You did mention the new plugin architecture, which is quite exciting.

Regarding the support of old machines, it doesn't matter at all, really. Even vim 1.0 would be enough for old machines. I'm not aware of anyone that wants to develop in an old machine. At most, you might need to ssh into it, and even vi is good enough :-)

Previous discussion: https://news.ycombinator.com/item?id=9263193

So that's why it got flagged off the front page so quickly. That was a while ago, but it's probably relevant that https://github.com/vim/vim was last updated within the last 24 hrs, so TFA which is also less than a day old is probably news and probably shouldn't have been flagged.

Sweet!

Hopefully this will give the project more exposure :)

Honestly, I'm really disappointed they chose GitHub over BitBucket.

Not because of any political reasons, but just because I love Mercurial and detest git.

Interesting. Just curious, why do you like hg more than git? Not trying to start a flame war, just interested in learning more about it.

Git was developed by kernel hackers for kernel hackers, and it really feels like it from an interface perspective. Git commands are baroque and arcane, and it's a pain in the ass.

Hg, on the other hand, was developed from a perspective of "let's make a distributed version of Subversion", which resulted in a much more user-friendly set of commands. It feels like using SVN, only with all the benefits of DVCS, which is a much better workflow for me because I came from an SVN background before I started using any DVCS.

It's also changeset-based rather than snapshot-based, which I find easier to deal with (again, because I come from an SVN background). It's also nice having revision numbers in addition to the hashes.

Oh, and I don't have to deal with staging-related headaches when working with hg, unlike git.

Why is that so? And how is this relevant to TFA?

Vim is currently using hg, as mentioned in TFA. Since GitHub doesn't support that without some shims, it seems likely that the project will move to git as well. Contributors who prefer hg might well be disappointed by that.

Its relevant because it forces a change to the DVCS used by the project and participants.

Maybe I didn't understand correctly, but the post doesn't specify whether the project is dropping Mercurial for good or merely changing hosts because of the impending closure of Google Code.

Reply on news.ycombinator.com