I'm sure neovim dropped a lot but I don't have the full overview. Prominently it dropped support for giving !commands access to the actual tty. Commands that access the tty have to be used through the command :term instead.

Neovim prominently dropped support for gvim as well (GTK UI). Instead they focus on being embeddable in new ways to create UIs.

What's wrong with all features enabled by default?

> I'm sure neovim dropped a lot but I don't have the full overview.

https://neovim.io/doc/user/vim_diff.html

>Prominently it dropped support for giving !commands access to the actual tty. Commands that access the tty have to be used through the command :term instead.

Why would you run an interactive command with `:!` ?

And about !, It's also listed as a thing that changed, no judgment. Regarding usecases I think if it's possible, some user will take advantage of it.

I ran up against this limitation recently. The kitty terminal exposes APIs allowing processes to communicate with the terminal using escape codes. I wanted to configure Neovim to access the system clipboard using kitty’s API, so that I could copy/paste from within Neovim even over SSH. However, this would require Neovim to give the clipboard subprocess access to the controlling TTY. (Running it within :term would not work, as the escape sequences would thus be passed to Neovim’s virtual terminal emulator, not the instance of kitty that Neovim itself is running within.)

It’s easy to implement OSC 52 copy with a simple script/plugin, but apparently not paste without adding some code inside of Neovim itself.

Why wouldn't you? Vi's `:!` is simple and general.

If neovim has an equivalent, it must be obscure enough that no one has mentioned it yet, and it seems to me that the obvious thing to do would be to make `:!` do it by default, and put neovim's current `:!` behaviour behind a `compatible` flag.

The closest neovim equivalent I can think of is :term <command>

They can compromise on the process and maybe aim for a medium to long term merge.

I.e. they start aligning coding conventions, standards, etc, and when they're ready 1-2 years from now they pull the switch and re-merge the code bases.

Unless the vim project gives that up (and there will be significant outrage over that), or unless the neovim folks give up that particularly shortsighted stance (having a first-party cross-platform pluggable GUI is a good thing), I do not see a merge ever happening.

Let's see how much traction Vimscript9 will get. From the distant view of an outsider I got strong NIH vibes from that.

> it would probably have to be Vim basically winding down development. Doesn't seem likely.

It depends on how much Bram was the main focus point of development and if the remaining contributors are able to transition to a less centric development structure.

I would rather expect a EGCS/GCC "merger" than a true code merger. But only time will tell.

In practice, none. It's a wasteland. Extensions that aim to be compatible with both vim / neovim use the old vimscript, while lua has very, very significant traction in the neovim world among people who try to bring IDE like feature to vim. The amount of people willing to write extensions that only work on vim proper, which is what would happen if they used vim9script, is close to non existent.

> I would rather expect a EGCS/GCC "merger"

Or libav vs ffmpeg.

Honestly, that's what most recent Vim development in the Neovim era looks like to me.

Bram rejected async patches for years. Neovim gets made and proves out the demand for async. Vim suddenly is motivated to cook up their own, incompatible version of async.

When Neovim began, I thought the inevitable future was the Vim project cherry-picking the best features from Neovim each time such a feature reached sufficient maturity and popularity, and merging Neovim's implementations back into the core project. I underestimated how strong the NIH syndrome was with Vim proper.

Open Source projects never have enough resources and splitting them into 2 clone projects is generally not great.

I know about competition but it's not like Vim/Neovim, programming text editor, is lacking in competition even without the other side of the fork :-)

You and meitham are very focused on this, but it is very much an opinion and not a fact.

Long lived forks are rarely good for an individual project. Frankly, the most successful forks I've seen unfortunately... kind of strangle off the original. Jenkins/Huson, LibreOffice/OpenOffice, MariaDB/MySQL, ConsoleZ/Console2/... Though there are cases where the original wins out: Emacs/XEmacs, etc.

Especially since it's not like Vim/Neovim are already lacking in features to implement, bugs to fix, ways to extend their architectures :-)

I do think there would be a lot to gain to merge vim/neovim, but they're in a very different position. I don't know enough about the other two forks to draw parallels to them.

MySQL 8 was released nine years after the split, and was one of the best releases throughout the project's history (cleaning up many decades old problems, modernizing the underlying storage engine, introducing window functions, CTEs, transactional DDL, lots of other stuff like that).

Without the forks, there would be no competition. Would the improvements have been included in the original project if there was no fork? Maybe. But usually forks happen because the intended improvements were either rejected or otherwise not accepted. If there was no fork, and the forked project did not "strangle" the original one, users would not have the chance/option to use the "better" one.

I think all you showed was that competition is good. I don't see how you would come to the conclusion that merging is better.

In a sense this is mostly a philosophical question of the Ship of Theseus kind. What happens is that when one side gains traction because of some specific feature, the other side either gets obsolete quickly, or they adopt the same features. So in the end everything converges in feature (and often even code), only not necessarily in name/leadership.

(You might counter that by saying that the last MySQL release was in 2018, but it's not really comparable: Oracle does all of its development behind closed doors and then does major code dumps when it's ready. MariaDB prefer shipping small releases every 6 months or so.)

It is fact that 1 + 1 > 1 if you compare available resources.

It seems a bit ridiculous to dismiss reunification when you don't even know what kind of compromises might be made to make it happen.

On the other hand, vim and neovim are almost the same thing, and wherever they diverge, it is always to the detriment of vim. I would not be very optimistic for the future of vim considering that nobody uses vim9script and that alone is quite the massive baggage to maintain, an entirely separate, new programming language? one that is used by.. no one? 99% of extension developers either use the old vimscript or lua, and neovim's lua base has significantly grown to the point where we can imagine a future that has no vimscript.

Where will they find people willing to continue working on vim's code base when it has this kind of really big, really useless baggage? and if they were to cut it out of the code base, would it still be vim? I respect Bram for his contribution to open source, and vim is one of my favorite, most used software, but his decisions in the past few years have been extremely poor and were not friendly toward the possibility of vim being community maintained.

They are quite different at this point and personally I prefer vim over neovim. I've never gotten NeoVim to work satisfactorily. I've had issues with the async setup where the backend and frontend start having issues with each other or lag. So on. Personally I find vim to be a lot simpler to work with and MacVim in particular to just be a perfect GUI for me.

Of course YMMV. The point being is that there are a many of us that prefer normal Vim over the NeoVim work. That's okay. Its also okay that others prefer NeoVim over Vim. There is nothing wrong with that. What there is something wrong with is the way that many NeoVim people are reacting to this.

the same place where neovim found its developers. if one group of people can organize themselves to maintain and develop their version of vim. so can another. i don't know how many contributors vim has, but i am sure they can figure out how to move forward. finding new leadership can be difficult when there is no clear candidate, but if the contributors had not wanted to work on vim they would not have been there in the first place.

Bram, for 98% of the commits/lines, plus some statistical noise.

it feels to me that not changing vim would be what bram would have wanted. any new developments may as well happen in neovim.

of course anyone who disagrees or doesn't like where neovim is heading may fork vim and make their own version of it.

Well, they were making a wrong, but also totally unrelated to the Vim/Bram situation comparison then.

This is not a huge multinational company with tens of thousands of employees, hundreds of billions in cash, hundreds of millions of users, a strong product lineup, and a strong C-level team, who has been preparing for 2 years for its CEO eventual demise, complete with another person taking his CEO role way before that happened.

As Apple was at the time of Job's passing.

This is a FOSS software project, strongly associated and mostly solely written almost predominantly by a single person [1], with another fork that has a vibrant community and more modern features.

[1] Bram has 16,515 commits, the next biggest contributor has 68 times less commits. Or, 1/50th lines added. And it goes downhill from there, with the rest of the contributors added together being 1/50th Bram's contribution as well.

Vim is a marquee project, tons of hackers will want to contribute because it's cool or because they want to have that name on their CV.

It's one thing to contribute a couple of PRs/patches, a very different thing to spend a large part of your free time on the project for years (which is what Bram did to make vim what it is).

These projects are no joke and a few hurray contributors not lasting more than a couple of months won't cut it.

Those same contributors that remained on vim instead of neovim didn't put much effort into vim9 ecosystem either. I can't imagine them being willing to maintain all of vim's baggage when literally nobody writes vim9script. Classic vimmers tend to stick to the old vimscript.

As you said, contributing a few patches to classic vim is one thing, but becoming an actual maintainer of the behemoth that comes with a ton of useless baggage is a whole another thing. Maintaining a programming language no one uses.. sisyphus would be proud.

Looking at the commit history, vim was largely a one-man show, I'm a bit skeptical about that changing basically overnight.

Related discussion: https://github.com/vim/vim/issues/1554

“Taken at face value by most modern users of Git, the commit history does not accurately reflect the contributions to the code-base”.