Live data from Hacker News

The Future of the Vim Project

groups.google.com

171–180 of 376 posts

Re: The Future of the Vim Project

#171
post #44

Earlier quoted context omitted.

I have no worry about the funds being lost. It’s just imagining my heirs having to contact and close fifty+ accounts.

Serious question: How common is having dozens of accounts? I live in NL and have 3 at the same bank. Why would anyone have 50+ accounts?

The US based financial industry is a make work project for bankers as far as I can tell. The US creates all sorts of classification of money causing the need for at least 3 retirement account types, a college savings account per Child per contributor.

I'm only scratching the surface of the number and types of accounts an American can have. It is also useful to have different banks for different services.

Re: The Future of the Vim Project

#172
post #65

Earlier quoted context omitted.

Another consideration, when my dad passed we had his passwords but not his phone or tablet pins/patterns. Both devices are encrypted, and the samsung I believe is set to wipe after a number of failed attempts. While there probably isn't anything on them, it's always been a pain to not know.

> While there probably isn't anything on them, it's always been a pain to not know. I know I wouldn't care because I'd be dead, but I really do not want my family getting on to my personal devices after I'm dead. Those are things that I will never give them the passwords for, not everything is their business.

I think that's fine; albeit a potentially awkward conversation, I personally would rather have known "hey, here's what you can get into, here is what is private" but we never talked about it at all.

Especially important to communicate that in your case, on the off chance they want to hire a data recovery firm in some hope of saving wedding photos or something

Re: The Future of the Vim Project

#173

Earlier quoted context omitted.

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

What’s wrong with clangd via lsp?

For one thing, LSP (last I checked) was still unable to distinguish between read and write.

Re: The Future of the Vim Project

#174
post #6
post #5

Earlier quoted context omitted.

Why not? vim and neovim have been separate for a long time already, wouldn't it work to continue like that?

There’s no future to Vim without Bram. A merge of the two fork’s isn’t what Bram has wanted, but it’s the best way to keep Vim alive

None of that is even remotely true.

Re: The Future of the Vim Project

#175
post #9
post #4

Earlier quoted context omitted.

Yes, although the forks have diverged quite a bit by now :(

True, but if there's a will, there's a way. 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.

There is one thing that vim provides that the neovim folks have said that they will never provide, and that’s a GUI.

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.

Re: The Future of the Vim Project

#177

Earlier quoted context omitted.

> While there probably isn't anything on them, it's always been a pain to not know. I know I wouldn't care because I'd be dead, but I really do not want my family getting on to my personal devices after I'm dead. Those are things that I will never give them the passwords for, not everything is their business.

yeah same here. Do I have to give out my passwords, or can I just make a doc with important things?

Doesn't matter as much what you do or how, but more importantly that you've communicated it to the people who will have to deal with your stuff if you were to kick the bucket tomorrow.

My parents simply made a list of passwords on a piece of paper, buried with the other important papers.

Re: The Future of the Vim Project

#178
post #31

Earlier quoted context omitted.

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.

I am not sure how you reconcile some of the philosophical differences between the projects. One of the first objectives of NeoVIM was to dump code for obsolete computing platforms. A ton of legacy code was deliberately removed so as to streamline the project. If I recall correctly, one of the reasons the original async patch was ostensibly rejected was because it would rely on a C89(?) compiler. That was considered t…

I think very, very, very few people still care about the C89 compiler.

A bigger blocker to a merge/collaboration would be the move to use Lua in neovim

Re: The Future of the Vim Project

#179
post #72

Earlier quoted context omitted.

Where will they find people willing to continue working on vim's code base 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 co…

> i don't know how many contributors vim has, but i am sure they can figure out how to move forward. Bram, for 98% of the commits/lines, plus some statistical noise.

i didn't realize that. given this and what others say about how bram treated contributions, i'd think it's best to put the original vim into maintenance mode and keep it as the version that bram intended. there is no need for another group of developers to emerge if it wasn't already there when they most likely would just end up repeating what neovim already did, since none of them would be a replacement to do things the "bram" way, especially considering that bram apparently was reimplementing many neovim features anyways.

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.

Re: The Future of the Vim Project

#180

Earlier quoted context omitted.

Anything with recurring billing needs to be cancelled, for a start.

Call the deceased person's bank to cancel all credit cards in their name and that's taken care of.

Your reply shows that you've never had to do this yourself. It's a lot more complicated than that.
Post reply on HN