Live data from Hacker News

The Future of the Vim Project

groups.google.com

311–320 of 376 posts

Re: The Future of the Vim Project

#311

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 me, it's the use of Lua. I switched to neovim in no small part for the sane defaults, the XDG layout support, and the async/terminal stuff (and I found the code simplification, addition of tests, and removal of ancient legacy stuff to be very appealing).

The terminal and async stuff has been "backported" to vim, as it were. But the plugin ecosystem is diverging. The other items are still open, and maybe those will move forward.

At this point Vim9 is the clearly superior language (don't hate me) since it's very domain-specific, while Lua has only very primitive hacky support. But the plugin ecosystems have diverged -- I don't see NeoVim coming back home without native Lua support, and I definitely don't want native Lua support in vim.

Re: The Future of the Vim Project

#312
post #243

Earlier quoted context omitted.

You're talking about two totally different things. GP is saying Vim users generally have muscle memory of their shortcuts (I might add, to the extent that some of them may not even be conscious which keys they are pressing). GP also mentioned that Vim takes less mental effort (due to muscle memory) and is faster. The faster part is easy to argue even from a theory perspective. Your hands basically never leave the hom…

> How is that relevant? I keep reading and hearing folk claiming that X is faster, as in this thread. It would be nice to read some actual study showing this to be true, but it seems like it mostly ends up being strongly held opinions based on anecdotes. You say it's easy to argue. Sure, it's easy to argue but that doesn't make it correct. I could argue in the other direction and then we end up wasting our time.

It's true for me, and that's good enough for me.

Perhaps an objective, statistical significant study helps you decide, but ultimately, some people are more productive in Vim, and some people aren't. A study just gives you the average, but it doesn't necessarily imply anything for your personal experience with the tool.

Arguing what is "correct" here is a waste of time TBH. Nobody is really trying to prove anything. The person you originally replied to was trying to answer "Why so many people love vim?" . It's not because it is "objectively faster for everyone who uses it, provable in a reproducible large scale study", but rather because people perceive it making them work faster.

You don't have to accept the answer. Just leave it be.

Re: The Future of the Vim Project

#313
post #288

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. 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.…

> Why would you run an interactive command with `:!` ? 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 for those who want it.

That does sound kind of like a missed opportunity. Not sure why it's not like that.

The closest neovim equivalent I can think of is :term

Re: The Future of the Vim Project

#314
post #41
post #7

Earlier quoted context omitted.

They're already getting to the point of being two different editors with a common lineage and legacy support for Vimscript. The Neovim people also probably don't want to re-merge with Vim, it would probably have to be Vim basically winding down development. Doesn't seem likely.

> They're already getting to the point of being two different editors with a common lineage and legacy support for Vimscript. 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 rem…

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

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.

Re: The Future of the Vim Project

#315
post #98

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?

MacVim and gVim. I've looked at neovim and there are many GUI options (paradox of choice), some of which I've tried, but at the end of the day, I'm more comfortable with what I'm already familiar with.

I did the Vim -> NeoVim switch a while back (pre-vim9script) and lack of standardized GUI is a non trivial issue. There are solution(s) - but allof them have had too much friction to fit in a workflow for me. Definitely a concern.

Re: The Future of the Vim Project

#316
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…

I am sorry about your brother.

When we talk about these things it is always assumed that we want our family to have access to our digital lives after we die. I have lots of pictures from shared memories that I want my family to have - and they already do.

Other things I want to die with me - things that were not shared with my family before I died shouldn't be shared with them after I die.

Why is it that we generally assume that we should get access to other peoples private stuff because they are dead?

Again, not trying to make this an attack on you.

And of course I am excepting getting access to bank accounts and insurance.

Re: The Future of the Vim Project

#317

Earlier quoted context omitted.

Useful checklist: https://getyourshittogether.org/ Others in this thread have talked about safety deposit boxes and buried crates. I'd add that you can just give some trusted party a normal encrypted USB flash drive, and eliminate the risk of getting absolutely rinsed out in the event of a house burglary by splitting the password amongst an arbitrary number of your other contacts using the Shamir's Secret Sharing alg…

I wouldn't trust USB flash drives with anything long term. Best archival method would be to print something out (perhaps an encrypted message in a QR code), have it put away somewhere secure, and use that for a key to unlocking everything else.

Yes, this, USB flash drives live at most 5 years or something. Things get even worse for SSD.

If we are talking just about credentials, you can just print the password and access instructions to a password manager and give it to the people you trust. This is one place were having a cloud password manager might be helpful, otherwise you would need to also provide the access to a device containing the offline manager (or a updated copy of it)

You probably don't need to keep a whole flash drive for credentials. Unless you also want to keep some other files secure without being on other devices

Re: The Future of the Vim Project

#318
post #288

Earlier quoted context omitted.

> Why would you run an interactive command with `:!` ? 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 for those who want it.

That does sound kind of like a missed opportunity. Not sure why it's not like that. The closest neovim equivalent I can think of is :term

`:term` is much more intrusive; you can't just `:!foo` and get on with what you're doing. For one thing, you can't `:term foo` with a modified file, which is not an unusual state when you're editing.

Re: The Future of the Vim Project

#319
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…

My condolences about the loss of your brother. My kid brother passed away a few years ago as well, and his digital footprint is one of the most vivid portraits of his last years, and to me a treasure beyond accounting.

I strongly second the imperative to preserve as much as possible in the event that any of us suffer a mischief.

Re: The Future of the Vim Project

#320

Earlier quoted context omitted.

FWIW you can use Neovim like Vim with your existing config, without any of the other stuff. That made the switch easy for me. Of course this means you'd rely on Neovim maintainers honoring that compatibility in future...

One of the things I really like about Vim is how it maintains compatibility with Vi. The manual obsessively points out features Not in vi. It retains some ill-advised things like :Print because Vi had them. Ancient platforms still work, supposedly. I care about this not because I used Vi (I never have) but because it’s less likely that some new Vim with a newer distribution release will do something I don’t expect. V…

Uhm if you read my comment it is specifically about how nvim doesn't change the preexisting behavior of vim. And if I were to believe you then compatibility with vim means compatibility with vi
Post reply on HN