Hacker News Reader

Bram/Vim had a clear minimalist philosophy. Many wanted More from Vim; namely things like Terminals, Async, better scripting, etc.

Bram wasn't going to add those updates/upgrades (for philosophical reasons). So the community did what OSS does; and forked/added them. NeoVim was born.

Others could (justifiably) contest, but that caused Bram to ~panic that Vim wouldn't be the primary 'vi' moving forward, and Vim updates (adding NeoVim features or equivalents, sometimes better sometimes worse) started coming out.

{Neo,}Vim is in a much better state functionally than it was a few years ago because of the schism; enough that I switched back from VSCode without missing (much). I am saddened by the split community now though.

> although I consider the removal of GUI support to be about as arrogant

They didn't just delete the GUI. They made it easy to embed neovim and as a result there are several GUI frontends now. Seems like a good call - gvim is not a great gui so why keep it around rather than making it easy for gui people to make good ones against an api? There are several active guis right now: https://github.com/neovim/neovim/wiki/Related-projects#gui

None of the ones that support macOS are good, and all of them that don’t have explicit macOS support are all awful.

Given the choice, I can either:

1. Hate every day of working with the substandard state of neovim GUIs

2. Hate every day of working with neovim remediated by a terminal

3. Switch to Emacs

4. Switch to VS Code

or

5. Keep using MacVim, because it just works

I try each of the various active neovim GUIs every few months. Usually, I end up noping out of each one with just trying to edit a single file. For ones that have stuck for a day or two, I end up noping out of them because they are missing key OS integrations or are sluggish or have made decisions to act more like an IDE (Vimr) that result in a UI that’s less flexible than gvim or MacVim itself.

You say that gvim isn’t a great GUI, but that’s a subjective — and IMO wrong — opinion. It is vim. It doesn’t try to be anything but vim. It doesn’t try to add IDE frippery (because you can implement all of that with vim plugins) or switch to an entirely different plugin system where you can’t use any of your existing configuration (Oni2).

gvim — and MacVim — are great GUIs for being separate non-terminal-bound views on vim. There’s not a single neovim GUI that has reached that level, and most of them get abandoned because, in the end, no one on the neovim ecosystem cares because the core project doesn't care.

So you have some subjective preferences, and that is enough to make you rage about a fork that didn't stop development on the original?

I would like so suggest you reconsider your priorities - all this anger over something existing is probably bad for your heart.

I suggest that you start reading for clarity and stop assuming that someone who feels strongly about something is angry. The condescension you’re expressing is both ignorant and asinine.

Oh sure, you're so not angry that you need to insult me for misunderstanding your ranty walls of text. My bad.

>None of the ones that support macOS are good, and all of them that don’t have explicit macOS support are all awful.

VimR is very good; I've been using it before it started using Neovim as the core [1].

[1]: https://github.com/qvacua/vimr

It’s not very good. It is perhaps the best available Neovim GUI, but VimR has been an unusable mess every time I have tried because it’s trying to be an IDE first and not Vim first.

Before I can take Neovim seriously, I need a Neovim GUI that is exactly what gvim or MacVim provide — not something that adds features I neither want nor need nor can I easily disable.

Granted, it’s been about six months since I’ve used VimR, but I bounce off it every time, because it doesn’t work with the configuration that I have built up trying to match my Vim configuration to the best of my ability.

>Before I can take Neovim seriously, I need a Neovim GUI that is exactly what gvim or MacVim provide — not something that adds features I neither want nor need nor can I easily disable.

Having used MacVim for several years and now using Neovim mostly in the terminal but sometimes VimR, I disagree that it's a mess.

I get wanting to have a common gvim ui/ux across platforms, but I think having a Mac-like or Windows-like ui/ux on those platforms mostly trumps that.

Also, the special features of VimR, like the built-in file browser and Markdown preview can easily be disabled. Using the native rendering of macOS and support for ligatures, for example, is certainly a plus IMHO.

> Because the patches weren’t accepted as is, they hard forked.

They weren't accepted for years, and if you're being honest, they never were going to be accepted. I'm guessing you thought Bram was also arrogant for forking vi?

You’re right. They weren’t going to be accepted, because they didn’t work the way that Bram thought they should and the people who pushed them would not change them to fit Bram’s goals. As package maintainer myself, if I get a PR/patchset the implements something in a way with which I disagree, I will not accept the changes. If I don’t care enough about the changes, then I probably won’t implement them either. Or I might do so later when I have time.

On the history of things, please be more precise. Bram did not fork vi. He worked from the Stevie code, which only ran on the Atari ST, so that he could use it on Amiga. It quickly expanded to other systems (I believe I encountered it after trying other DOS-based vi-like editors). That expansion eventually made it into the relative juggernaut it is today.

So... Bram won't accept their input, so they go make their own product with their input, and you call it arrogance. Got it.

You have every right to disagree with people's patchset, just as they have every right to disagree with your direction and decide to do it their own way.

I think that you’re intentionally misunderstanding, because that’s not at all what I said.

The arrogance is twofold:

1. Their way or the highway. It wasn’t that Bram wouldn’t accept their input, but that would not accept Bram’s input and change the patches to be closer to what he wanted for such a feature. He would not accept their input under their arrogant terms.

2. Their continued description of Neovim as a "continuation" of Vim—as if the development of Vim had stagnated (it had not, it just wasn’t at the pace that the Neovim developers wanted). It’s a garbage statement that should have been removed five minutes after it was first stated, unless the person making (and continuing to make) the statement is so arrogant that they can’t see that it’s an outright falsehood.

Frankly? I don’t care that Neovim forked from Vim. IMO, it’s got some interesting ideas overshadowed by a core team that is careless with its language and some of its technical direction (see elsewhere on the treatment of ACLs, which makes neovim fundamentally unsuitable as a system editor). As an editor, I think that it’s less mature and stable than vim. I think that the use of Lua is interesting, but that the Lua/Vim API is less than useful. As an experimental testbed for some neat ideas…good on them.

Could I contribute to neovim to fix some of the issues that I have with it? Sure. I don’t want to, though, because on the whole I find the attitude from the neovim developers to be unwelcoming. That could be fixed by removing unnecessarily inflammatory language and no longer lying about the origins of neovim.

Forks can be good, even if there is no cross-pollenization between the projects. Look at the success of egcs. But they aren’t good when they’re founded on lies and ill will.

Frankly? I don’t care that Neovim forked from Vim.

I don't mind your indigination -- you've given neovim v. vim more thought than most. I do mind when pointy heads say "I don't care" when they clearly do.

Point of clarification: I don’t care about the fork. If you want to go a different direction than a parent project, that’s absolutely what you should do.

I do care about the way that the fork happened and the misrepresentations of the fork, so I’ve written way too many words about this today.

IIRC GUI support was taken out because one of their long term goals was (is?) to reduce the codebase and to make neovim something you can plug into any text input field. You could use it as a backend for a standalone GUI app, or in Firefox for leaving HN comments. I seem to recall they had plans for an official GUI after they got to a certain point. Not sure if they still do.

> That requires an incredible amount of arrogance.

Or pragmatism?