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

31–40 of 376 posts

Re: The Future of the Vim Project

#31

Post by bombcar »

goku12 wrote: post #25
oblio wrote: post #12

I hope both Vim and Neovim extend olive branches (and Git branches where it makes sense! :-D ). Even if the fork doesn't heal, if they could align the code bases to bring them closer, both sides win.

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.

These types of mergers have occurred in the past and it usually is the dominant project adopting the use and feel of the features the other has different. Shells acting differently depending on how you call them, for example.

Re: The Future of the Vim Project

#32

Post by AlecSchueler »

goku12 wrote: post #25
oblio wrote: post #12

I hope both Vim and Neovim extend olive branches (and Git branches where it makes sense! :-D ). Even if the fork doesn't heal, if they could align the code bases to bring them closer, both sides win.

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.

Are you sure it's not a fork? From their project wiki:

> Neovim is a project that seeks to aggressively refactor Vim source code

> It is important to emphasize that this is not a project to rewrite Vim from scratch

Re: The Future of the Vim Project

#33

Post by oblio »

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?

Inertia.

Such base programs basically need to go through the Debian packaging gauntlet if they want to succeed.

What I mean by that is that generally they need to persuade distros to be anointed the "official" tool, i.e. Debian or Fedora would have to select Neovim as the new default text instead of Vim.

Then you need a few years for the changes to trickle down everywhere: Debian -> Ubuntu-> Mint -> ..., Fedora -> RHEL, ... After that distro releases need to be cut and people need to upgrade.

I think a full cycle, where a tool becomes ubiquitous if it gets adopted in the base installs, is probably 10 years. See systemd.

Re: The Future of the Vim Project

#34

Post by suprjami »

djtango wrote: post #24
suprjami wrote: post #18

Earlier quoted context omitted.

I don't. Neovim have dropped "old useless" features which are the entire reason I use Vim.

I've not tried neovim mostly because I'm hopelessly loyal. curious what features were cut?

vim-cscope, which is the only reasonable way to read large C projects like the Linux kernel or BSD

Re: The Future of the Vim Project

#35

Post by suprjami »

random_mutex wrote: post #26
suprjami wrote: post #18

Earlier quoted context omitted.

I don't. Neovim have dropped "old useless" features which are the entire reason I use Vim.

What features?

vim-cscope, which is the only reasonable way to read large C projects like the Linux kernel or BSD

Re: The Future of the Vim Project

#36

Post by biorach »

goku12 wrote: post #25
oblio wrote: post #12

I hope both Vim and Neovim extend olive branches (and Git branches where it makes sense! :-D ). Even if the fork doesn't heal, if they could align the code bases to bring them closer, both sides win.

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.

No, Neovim is a fork

> Neovim is a refactor, and sometimes redactor, in the tradition of Vim (which itself derives from Stevie). It is not a rewrite but a continuation and extension of Vim.

https://neovim.io/charter/

Re: The Future of the Vim Project

#37

Post by pmckenna »

OskarS wrote: post #13

My brother passed away very suddenly a few years ago, and I was put in charge of wrapping up and archiving his "digital" life. We were very lucky that we had access to a recovery email for his main gmail account (as well as a couple of passwords that his partner knew) and was able to access and archive virtually all data we could think of (services like Google Takeout were invaluable). I realized that if this had hap…

Weirdly this is something I’ve been thinking about a lot recently. I had no idea 1Password provided a recovery kit until you mentioned it. Just had a look and looks good.

I’ll definitely go through the steps, but I’m wondering what the best way to store it is. Feels weird keeping a document lying around giving access to all your passwords, bank cards, finances etc.

I’ll have a think about storage.

Re: The Future of the Vim Project

#38

Post by oblio »

goku12 wrote: post #25
oblio wrote: post #12

I hope both Vim and Neovim extend olive branches (and Git branches where it makes sense! :-D ). Even if the fork doesn't heal, if they could align the code bases to bring them closer, both sides win.

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 think there was bad blood there with Bram, I'm not sure how deep the emotional rift was between the 2 groups. From the outside a lot of it looked like stubbornness on the Vim side, at least 60% of the time..

Re: The Future of the Vim Project

#39

Post by petepete »

sdfghswe wrote: post #30
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?

From my admittedly somewhat limited experience, neovim felt a bit more sluggish to launch. Not a good sign.

    nvim --clean --startuptime /tmp/neovim

    003.174  000.001: --- NVIM STARTED ---
vs

    vim --clean --startuptime /tmp/vim

    004.274  000.001: --- VIM STARTED ---
Maybe your config had an impact on it, but config-free they're incredibly close.

Re: The Future of the Vim Project

#40

Post by kzrdude »

random_mutex wrote: post #26
suprjami wrote: post #18

Earlier quoted context omitted.

I don't. Neovim have dropped "old useless" features which are the entire reason I use Vim.

What features?

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 prominently dropped support for gvim as well (GTK UI). Instead they focus on being embeddable in new ways to create UIs.

Post reply on HN