Hacker News Reader

Hacker News

Comment by pensatoio | Hacker News Reader

Full thread

pensatoio

Imagine if more people were allowed to contribute. Neovim is the horse to back, now.

View on HN

What are you talking about? Everyone is allowed to contribute. Did I miss something?

I think what parent is implying is that it is difficult to get a commit past Bram Moolenaar.

I see huge amount of PR merged with VIM on daily basis send by other people.

I think that every open source project used by thousands of people should have person like Bram. Who will draw a line and separate low quality or effort PRs. Many hate it and call them dictators, but that's just taking care of your own project, and keeping it at the highest standard.

I think no open source project should have a maintainer who answers the question of how to make the project succeed in the future with:

“Keep me alive” [1]

[1] https://www.binpress.com/vim-creator-bram-moolenaar-intervie...

That's what is technically known as "a joke".

I took a quick look at the contributor graph:

https://github.com/vim/vim/graphs/contributors

Other than one solitary commit, that graph makes it look like every single one of the 13,000 commits to Vim has been made by Bram. What's going on there?

Incidentally I wondered what caused the huge jump in commits that has been sustained since the beginning of 2016. I thought initially that may have coincided with the announcement of Neovim, but that announcement seems to have been a couple of years earlier. Maybe it took a couple of years for Neovim to see significant adoption though.

Patches are send to mailing list, and Bram commits them do repository after review. Each contribution is credited in commit message, and VIM docs.

I like this approach better than GitHub “everyone send us a PR”. These days having a “change a typo” PR to show activity on GitHub is appealing to masses, but mailing list sifts out people who don’t have anything serious to add = less work in managing open source project. As we can see lot’s of maintainers have a problem with that, and users that demand stuff (at least once a month there’s a topic about it on HN). :-)

Thank you. Having a mailing list based workflow is fairly common for long established projects. That doesn't seem to preclude setting the Author field to the actual author when Bram lands people's contributions though. Unless that's an additional layer to discourage low value contributions by eliminating the visible credit people would get in their github commit history. Are there other projects that do that?

As I mention before, each of contributions is credited on GitHub commits, and VIM docs. So you still can showcase those in your portfolio, by writing case study or short information as it was before GitHub... :-)

I did a PR regarding some rarely-used setting a couple of years ago, as part of a uni course in architecture. It wasn't merged immediately as I didn't write tests for it, but Moolenaar wrote the tests himself later, and merged it.

https://github.com/vim/vim/pull/3539

https://github.com/vim/vim/commit/375e3390078e740d3c83b0c118...

Well neovim folks forked vim bacause they were not allowed to clean up the code and fix vimscript among other things IIRC.

It is very unfortunate that they could not find an agreement.

From my understanding they forked it over disagreement for terminal implementation in VIM based on bunch of unfinished code. Which Bram didn’t wanted to add until it’s properly implemented.

Well, The Vim's BDFL is not that benevolent after all, hence the neovim fork.

As one who depends implicitly on Vim, he seems to me very benevolent: he doesn’t let other people break Vim.

I greatly appreciate Vim’s stability. But it’s also not only Bram that can develop it, especially on maintenance patches (as distinct from new features). I can’t think of any particular times anything regressed in Vim, except that I have a feeling there was one. A few times over the years I’ve found bugs, and each time, I’ve either submitted a patch which has been rapidly accepted, or reported the bug and it’s been fixed rapidly by Bram or someone else.

I just checked the GitHub project for neovim and see that their CI is failing. That maybe is a good symbol of the differences in priorities

You might want to check the CI history of vim too if you want to compare meaningless metrics.

https://github.com/vim/vim/actions?query=workflow%3A%22GitHu...

BDFL is not about taking any code that people throw at you. Look at LKML at how many iteration patches go through before they are merged.

TL;DR; neovim is garbage and the maintainers are arrogant. It’s a project that can’t die soon enough.

If you’re actually proficient with vim and you’ve tried neovim, than you know that the “shiny” is quickly overcome by the lack of core functions and system integration that makes vim a power tool to begin with.

If you want to use neovim, then you don’t understand what makes vim great in the first place. Here’s a hint: it’s not the key bindings.

And, the maintainers don’t care. They refuse to fix years-old bugs and feature requests. I believe it’s because they’ve painted themselves into a corner with their inexperience and lack of pragmatism.

Because it’s worth giving an example of its glaring mistakes, open up neovim in the terminal and “:!python” ... huh, doesn’t work ... that’s because neovim doesn’t have shell IO from processes it launches. When I googled the issue I found a feature request from 2013-ish. I can’t say anything now, because when I bumped the issue I was told that “ThIS ISn’T a cOre FeatURe, gvim diDn’T haVe THIs uNTil ...” and they closed the feature request at that. No fix, just a “f-u-very much” and the door. I had already posted a few other bug reports / feature requests, but promptly deleted them after that response. I’m done with neovim, except for recommendations that nobody use it.

Use real vim. Donate to help Uganda. https://iccf.nl/news.html

I found your issue and that's not at all how it went down. I don't think they were the ones being arrogant.

https://github.com/neovim/neovim/issues/1496

Edit: I missed the hidden comment the first time around. For those that can't log in:

https://imgur.com/a/ysEiIkL

I have never used NeoVim, but I am genuinely flabbergasted at the idea of not considering it a bug that :! is not interactive. I would consider that very close to fundamental functionality; I know that lacking it would make me stumble from time to time, and I’ve seen various other Vim users and plugins depend on it not irregularly also.

I’m not confident I know just what’s meant by “gvim did not support this until 1-2 years ago”. Opening the command in a Vim terminal, sure, that’s recent functionality (as is the whole concept of a Vim terminal), and opt-in at that, but on MS-Windows at least, from time immemorial :! opened the command in a separate console window, meaning it always worked. Not sure what it does on other platforms, as I’ve long used terminal Vim exclusively.

Also it sounds like they haven’t actually fixed this, just implemented the equivalent of Vim’s guioptions+=!, which… well, that’s definitely not how I want it to work.

Oh yeah, that is my final reply to the thread on git, for sure.

They are arrogant, and you’re welcome to not take my word for it. And, I will use continue real vim.

Also, I will continue to disparage neovim. And, the issue still is not resolved. I will also continue to not give a fuck what they do.

I believe your example will be fixed in nvim 0.5: https://github.com/neovim/neovim/pull/10842

Reply on news.ycombinator.com