Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of the Vim Project

groups.google.com

Post reply on HN
Print view View original

261–270 of 376 posts

Re: The Future of the Vim Project

#261

Post by thefifthsetpin »

guhidalg wrote: post #254
BanazirGalbasi wrote: post #251

Earlier quoted context omitted.

I feel like I've said the same thing here 3-4 times now, but for some of us it's about what's the most minimal setup required to use the tool. As a sysadmin, I want to be used to the most common tools and configurations that will be on a server without having to take the time to install something new. I could include NeoVim in my Ansible configs for setting up new servers, but generally servers are kept lean so I wou…

Serious question: how is neovim “heavier” than vim?

vim often ships with the base image, so you'd be comparing installing neovim on top of that to installing nothing.

Re: The Future of the Vim Project

#262

Post by colordrops »

plugin-baby wrote: post #74
fortunateregard wrote: post #17

What is it that prevents the rest of the vim community from adopting neovim? From what I can observe, a great deal already have. But for the folks holding out, what is it that outweighs all that neovim has to offer?

I tried switching recently, mainly because I wanted treesitter. I couldn’t get it working after half a day messing about, a lot of documentation seemed out of date, and I don’t think my standard plugins + .vimrc worked out of the box. My main focus is getting things done, not fiddling with configs and versions, so I gave up. I figure I’ll try again in a couple of years if it’s still tempting.

I fiddled with it for half a day 5 years ago to get it working and have reaped the benefits for 5 years.

Re: The Future of the Vim Project

#263

Post by gorjusborg »

maleldil wrote: post #139
gorjusborg wrote: post #100

Earlier quoted context omitted.

> You should ask, and answer, the question in reverse. What does neovim offer me, as a regular vim user? Well, one of the goals of neovim was to make it easier for new people to contribute. So, there's an obvious feature you might be overlooking: the project surviving past its creators passing. Beyond that, async, lua, lsp and treesitter support are other things neovim brings to the table. I don't use vim much anymor…

I know you listed Lua already, but it's important to stress that. Bram _did not_ want Lua as the main scripting language, and created Vim9 Script as a "better VimScript" instead. That's a stark difference in the direction for the project, and it signals to me that Vim is not meant to reintegrate with Neovim. It's no longer a question of Vim catching up with Neovim. However, this was Bram's vision. We don't know how t…

> Vim9 Script as a "better VimScript" instead. That's a stark difference in the direction for the project

Great point. I wasn't following vim much, so didn't know the context around the language changes.

That does seem like a core philosophical difference. I'm interested to see what the future holds.

Re: The Future of the Vim Project

#264

Post by fatbird »

oblio wrote: post #38
goku12 wrote: post #25

Earlier quoted context omitted.

Neovim team has always been positive towards Vim. This post doesn't paint the Vim team as being hostile either. However, I really wonder how practical a merge is, considering that neovim isn't a fork or Vim, rather an implementation from scratch. Edit: Looks like I'm wrong about neovim not being a fork of vim.

It's not an implementation from scratch, do you know the history of the projects? Neovim started out as a large clean up and refactor of Vim code, plus the addition of async code. That's a huge amount of work, partially re-implemented by Vim (Bram implemented his own version of async). Actually, after the Neovim launch a lot of the Vim features were just Bram chasing after Neovim features. Vim9script, :term, etc. I t…

I don't think there was bad blood with Bram. Rather, vim was always Bram's baby, even with contributions from the community, and he was very opinionated about how things should be implemented. IIRC, he found the new features of neovim interesting enough to want to implement them his own way, and a couple times commented that he thought that neovim's approach to certain features was "wrong," to his way of thinking.

His choices were always a bit idiosyncratic, but the success of vim justified them, so it was never a problem... until he died, and now there are two projects, one of which is very modern, both in terms of the codebase and how the project is managed, and the other is likely to become something of a legacy project unless someone as dedicated as Bram is found to take over.

Re: The Future of the Vim Project

#266

Post by stcroixx »

fortunateregard wrote: post #17

What is it that prevents the rest of the vim community from adopting neovim? From what I can observe, a great deal already have. But for the folks holding out, what is it that outweighs all that neovim has to offer?

For my use case of simple editing, vi was feature complete like 30 years ago. I don't have any preference at all what open source project build implements those features.

Re: The Future of the Vim Project

#267

Post by fatbird »

nzach wrote: post #220
oblio wrote: post #38

Earlier quoted context omitted.

It's not an implementation from scratch, do you know the history of the projects? Neovim started out as a large clean up and refactor of Vim code, plus the addition of async code. That's a huge amount of work, partially re-implemented by Vim (Bram implemented his own version of async). Actually, after the Neovim launch a lot of the Vim features were just Bram chasing after Neovim features. Vim9script, :term, etc. I t…

>Neovim started out as a large clean up and refactor of Vim code, plus the addition of async code. I don't think that is actually true. As far as I remember Justin and Thiago (I think) wanted to implement the ':term' into vim and Bram just shut them off because he didn't wanted to lead Vim into the road that Emacs went. And this was what prompted the Neovim fork. And they took the oportunity to also make a big refact…

It was async that Justin and Thiago tried to add to vim, and spent several months wrestling with Bram to get their patch included. At the end, they concluded that they weren't going to get it in and that a fork was necessary. Including the terminal followed quickly after neovim was set up and organized.

Re: The Future of the Vim Project

#268

Post by bongobingo1 »

ftaghn wrote: post #127
pmoriarty wrote: post #105

Earlier quoted context omitted.

How much of the rest of the vim ecosystem is Lua-based, though? As far as I know it's still mostly vimscript. Vimscript's dominance in vim is one of the things that got me to switch to emacs when I got interested in Lisp and Scheme more than a decade ago. Sure, even then I could write scripts for vim using Vim's scheme compatibility mode, but I'd probably be one of the only ones doing so. Pretty much everyone else wa…

> How's the vim ecosystem now? Is vimscript still dominant? You can have a full neovim experience with all sorts of modern extensions without using a single line of vimscript. Some people even replace their init (neovim's vimrc) with lua, but I am of the opinion that it is a step too far, as lua isn't particularly adapted to writing configuration files and the result is too verbose to my taste.

Ah you see, you just wrap that lua in a lisp in some terse macros and there you go, instead of writing `:set formatoptions+=j` (yuck, vimscript!) or `vim.opt.formatoptions:append"j"` (vom, lua!) you can write the clearly superior `(opt formatoptions +j)` (heck yes, ivory tower).

Re: The Future of the Vim Project

#269

Post by hnfong »

oblio wrote: post #20
tokai wrote: post #15

Earlier quoted context omitted.

>better if they merge You and meitham are very focused on this, but it is very much an opinion and not a fact.

It is an opinion backed by watching Open Source projects for several decades. 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/Neo…

The ones that "strangle off the original" are the successful cases. It means that users were given a choice, and they chose to use the forks, which were (for them) "better".

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.

Re: The Future of the Vim Project

#270

Post by kzrdude »

random_mutex wrote: post #258
kzrdude wrote: post #40

Earlier quoted context omitted.

One "meta feature" that was dropped was the ability to build the editor with or without different features. vim --version shows a long list of +/- features, neovim doesn't do that. 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 prominen…

>One "meta feature" that was dropped was the ability to build the editor with or without different features. vim --version shows a long list of +/- features, neovim doesn't do that. 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.…

What's wrong? I didn't mean it like that, I've just listed it as a thing that was removed.

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.

Post reply on HN