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 happened to me, it would have been virtually impossible to do, as all my passwords and credentials are in my password manager, and the password to that was only in my head.
It's a good thing to plan for this eventuality, to make it easy for your family and friends to wind up your "digital life" after you've passed. 1Password has a very good solution for this, with a "recovery document" you can print out and write down your password on, which contains instructions anyone else would need to access your 1Password account. I gave a copy of this document printed out to a small number of people I trust implicitly.
You never know when something sudden can happen to you. For the sake of those you leave behind, it's a nice gift to plan for this eventuality, even if it seems far off at the moment.
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 algorithm.
If you put at least 3 of these
on top of each other, my Google
recovery code will appear here:
2 £ 3 > ]7 7#A E
(each with different characters shown, of course. Ask a mathematician to make sure any 3 will show the full code, and any 2 won’t show enough to recover it)
Put them in envelopes, write “open in case John Doe dies” on them, and distribute them among friends.
If you distribute enough of them, I think there’s a reasonable chance they’ll recover your data.
As an improvement, distribute them not to your friends, but to their kids (the probability is higher they’ll be sane of mind when you die), and tell your attorney who has one.
I think that’s overkill, though. I’ve done it simpler: I wrote the full recovery codes down a few times and put them in a few places in my house.
I think that’s fine if I assume burglars won’t take them or won’t know what to do with them and I won’t die in a disaster that also destroys my house.
As someone who _has_ had their house burn down and had to recover their digital life from backups (successfully), this is why I've not made the step to yubikeys.
I'd say a regular will, sealed at a notary is just okay.
If you are really paranoid, why not write a service that works like a dead mans switch and when you don't trigger it for n days it sends all the keys to the kingdom to those who should receive them.
At this point I've moved almost everything off Google and basically now only use my Gmail account for logins on websites I don't want to give my real email address to and to keep Inactive Account Manager setup to send the necessary info to get into my 1Password account to my brother if I die.
I have a will setup with all my financial details and have set beneficiaries everywhere but this feels like a good backup in case I forget to update it with something or my family has trouble gaining access using other means.
That’s a helpful link! Do you know if google allows access to Gmail once inactivity is triggered? Ideally my contacts could use it to recover access to my password manager.
You have the option to allow that yes. When you add people to be contacted you're able to granularly decide what parts of your google account they get access to and can optionally add a personal message as well.
I am picturing a room full of non-programmers staring at all these documents, codes and Docker commands and saying “Well, Greg was obviously crazy. Instead of leaving any of his passwords, he just left pages of gibberish. I guess we’ll never be able to access anything.”
Me too, but then I realise that one should include at least a few tech savvy friends - or references to good coworkers or similar which these friends could contact.
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
Bitcoiners have been thinking about this storage problem for a decade now. Secure electronic devices in faraday cages and tamper and water proof bags or engraved steel plates (possibly cut up and distributed) seem to be the way to go for storing small bits of extremely valuable information.
Or of course you can use multiple key storage techniques and have a 2 out of 3 or more type setup. It all depends on how valuable the information is.
Security against unauthorized use and data lifespan are separate concerns. They're not fully orthogonal—security tends to make things more brittle—but you can apply whatever form of security you like and then store the secured data in any way you like. Hardburn seems to have been talking purely about the useful life of the archived data. The charge in flash storage leaks, so the data is eventually lost if not refreshed. A flash drive is reliable for a year, but not a decade. If you want long term storage you're going to want something else. Paper would be fine for most uses. An ordinary printout subjected to ordinary handling is good for a few decades with reasonable storage conditions.
I had a similar situation where I lost my brother very unexpectedly. I ended up having to run a password cracker on his windows account because nobody had a recovery email. Thankfully his windows credentials were not very strong and his gaming GPU was able to crack the password in a few days using a Linux livecd, and I was able to expand from there into his 1Password account. Like you, I realized that having a trusted second party with the keys to my digital kingdom would be a wise choice in case of a disaster.
This is one of the reasons that I’ve begun to pare down the number of online financial accounts I have, even though churning for bonuses is fun.
Every single one will have to be dealt with eventually by someone, so if I can reduce the number of banks I deal with it’s worth it, even at some small cost of not being “perfectly optimal”.
Yeah I used to have a massive spreadsheet tracking the entirety of household finances. I was worried that no one would know where the money was if I suddenly died, so I started a monthly finance 1:1 with my spouse. Even wrote an "upon death or incapacitation" playbook for her.
The second session was just her saying WTF I can't keep track of the location, ownership and tax benefits of 40 accounts!
I've since closed 3/4 of all accounts because of that.
The killer for me was working out how much time I was spending playing Excel Warrior and how much it was “making” me and realizing that I was working in my free time for Pennie’s.
that is what keeps me from getting into all this detailed finance management or worse trading, likewise any other side business that could earn some money but just isn't the kind of work i want to do.
making a budget is useful, as is tracking your expenses, but that's about it for me.
Banks are the last thing I'd worry about (I wouldn't) - they're highly regulated, audited, and have been dealing with this forever, since before 'passwords'.
Additionally, if you don’t list a beneficiary on any of these accounts, they have to go through probate court to gain access. The fewer hurdles and headaches that your loved ones have to go through the better. Having dealt with this early this past year with a family member, having the list of “chores” to do upon passing helps and reduces the headaches. Especially if those funds are necessary to pay for the sudden bills that a funeral and so on can bring up.
My wife and I have four kids and for each of them is a personal savings account, a savings account we keep for them to accumulate over time to avoid a taxable lump sump “gift”, and a tax advantaged educational savings account. For ourselves we have brokerage, savings, checking, and each have pretax and post-tax advantaged retirement accounts and health savings accounts. Many tech employees would also have 401k and possibly equity compensation accounts. And then any credit or debt (mortgage) accounts on top of that.
Our family is big, and the number of accounts scales with the number of people, but that’s about 25 without getting into anything moderately interesting.
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.
Pretty common in the US verses the EU/UK. The basic middle income set would be:
A checking account
A savings account (might be at the same institution as the checking, might not)
From your employment you may have.
- A 401k Account
- A Health Savings Account (HSA)
- A Health Flexible spending account
These will be at whatever institution your employer uses. As these change every time you change jobs you might have multiples of these in play unless you are diligent in rolling over and closing old accounts.
You also might have:
- Individual Retirement Account (possibly two, one Roth, non-Roth)
- College Savings Account (if you have kids and want save for collage in a tax friendly way)
- Money Market/Broker account for stocks etc.
If you live in a community property state then you probably have a second set of some these so you that you don't mix individual assets with community assets.
Market consolidation has made it easier to go with an single provider for a lot of the above, but it's still busy work keeping on top of everything.
The only reasons I can imagine are fund transfer times, and some isolation security for big amounts. As a fellow dutchie, I just use one bank for personal, and one for my business.
You sign up for them and never close them. I probably have nearly 50 credit card accounts alone and since they're free of monthly/yearly fees, I really don't have much motivation to close them.
On top of that I have two retirement accounts, four bank accounts (not counting various accounts AT those banks), and more. They collect if you don't weed them out.
Someone may have chequing+saving at one bank, a stock brokerage (or retirement savings) account at another institution, and a may have credit card(s) from completely different one(s).
So that could potentially be (at least) three different financially-related accounts.
Not so uncommon in NL. As a Dutchy you should have heard of Bunq which allows you to open unlimited accounts. The idea is to use each as savings pots for specific things such as a holiday, car, groceries, etc.
Other banks allow the same thing via virtual accounts.
Sign up bonuses. Some give an extra few percent on interest when you sign up, so you move all your money in, collect, then close the account out and go to another bank and repeat.
It’s not necessarily related to wealth (except that you need some savings), but when ING Direct was a thing my wife and I had an account for every savings goal and used it as our “envelope” system. There was no cost per account and you could open one in seconds, so we had a bunch of low value (dozens of dollars! Dozens!) accounts for saving for our next phone or vacation. That could have been done with a spreadsheet, but it was less work to just make separate accounts.
> all my passwords and credentials are in my password manager, and the password to that was only in my head.
It’s not just death I worry about. Anything that causes me to lose my memory of the password, from disease to head injury, leaves those trying to help me locked out of everything.
A password manager is an incredibly helpful tool to leave behind, it’s a compiled list of all vendors you have registered an online account with.
But, IIUC, without legal authority to access those accounts on my behalf it might not be sufficient. I’m planning to talk to an attorney that specializes in taking care of the legal side too. IIUC there are accounts you need legal authority to access even if you have the password. For example, if I give my friend the password to my 401k with the purpose of managing my estate, them using that password can put them in a legally gray area.
Also planning to work out a rough order of importance and context for a subset of accounts can help. Like writing down which financial vendor is managing the life insurance policy and whether that’s tied to my employer or not (if I lose my job leading up to my death, I.e. during a long battle with an injury, will I lose my life insurance before it pays out?)
A “red binder” project is on my families short list - the “I’m dead or incapacitated, here’s what you do” playbook. The above is how I’m thinking about things. I would love to hear more thoughts/perspectives
> But, IIUC, without legal authority to access those accounts on my behalf it might not be sufficient.
Relatedly, most digital accounts explicitly don't survive the user in their Terms of Service agreements. I think there are a lot of legal battles to come over digital inheritance rights for accounts like Movies Anywhere and Steam and App Store purchases.
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
> 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
I share any photos with them they might want, but I hopeful that Apple's security setup prevents any practical data recovery. I know my family too well, if I explicitly said "this is private" they'd be trying to get in the moment I was cold.
There's nothing bad on my devices, but there's lots they don't need to know about me.
Imagine once bronies age enough that they kick the bucket en masse and their families spend tens of thousands on data recovery only to discover "damn, that's a lot of horse porn."
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.
I have a doc, which is password-protected and shared with my wife. It contains details of bank accounts, how to access shares, who we're insured with and passwords / passcodes for things she might need access to.
i have all the family photos on encrypted devices, and the most efficient way to share them is to share the passwords for those devices. my phone they don't need because the important stuff from the phone is backed up anyways, so they just need that backup.
so i guess the easiest way is to keep separate backups of stuff you want to keep private and stuff you want to share.
My brother-in-law's mother passed away last year and he was in a similar situation. Even beyond the digital realm, there are so many details in a person's life that have to be attended to. Insurance, mortgage, vehicle ownership, etc etc. It's really an overwhelming process and it took a toll on him.
I've been thinking about building a platform to help prepare for and guide families who are faced with this kind of situation.
I had to go through this for my Mom an ex-pat in Israel. The account I was using was a joint-schwab account we had shared for 2 decades.
I mentioned to Schwab that she had passed and they froze the account until I could prove the estate was less than $14 Million. Needless to say this was a disaster as I was in a foreign country writing checks left and right.
The issue was that it was foreign addressed account of a US domiciled bank. The IRS places the liability of the taxes on the bank if the estate is over $12 Million. Schwab would recognise a letter from the IRS stating that or any US probate court. My Mom's estate with no US assets has no US based probate court access. The IRS rule was enacted after our joint-account was opened and blew up our estate plan.
Needless to say in 30 years I only had one problem with Schwab (which I had praised as the best bank ever until that moment). I have been unwinding all of my families Schwab accounts.
I think the hard part is more that it's difficult to focus on the business decisions against the background of a loved one's death, more than the process itself is difficult.
You pretty much need an estate lawyer just to navigate all of the legal stuff associated with a person's passing, and I went through this a few years ago with my own father.
But the majority of attorneys who handle estates can also handle all of the financial and personal details as well. The only times this really NEEDS to get complicated is when the estate has a negative net worth (which means a potential lack of funds to close the estate), contains businesses that need to be sold or split up, or when survivors fight each other for their percentage of the inheritance.
I've recently been planning for my death, no urgent need, but you never know.
I've put a backup of my keepass passwords on a USB as well as a printout of the passwords and the master password in a firebox. I also keep a list of assets and financial accounts in there along with birth certificates and passports. My spouse and I both have a key.
I would have used a safe deposit box but those are disappearing.
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.
My system is a little custom and complicated and tailored for me specifically, but basically my device periodically sends a ping to a service I built in cloud. I also have something like the google inactive account manager set up which is probably easiest for most people who use gmail:
I'm lucky enough to never have been put in this situation, so please excuse my ignorance: why does someone need to be able to sign in to my accounts when I'm no longer?
Lots of other people have mentioned very good practical reasons (and you can read the linked post for others, like people being unsure of what the password to the Vim FTP is), but there are lots of good sentimental ones as well.
When something like this happens, you lose your mind slightly, and you become obsessed with preserving whatever is possible to preserve of the person. I went so far as to record his voice-mail message, just because I felt i needed to.
Of all the internet stuff, the thing that was most important to us was photos: he was a photographer, and he used a photo-uploading service (I think it was Google Photos, but I'm unsure, it's been a couple of years) and I was able to get an archive with all his thousands of photographs.
Eventually, I put everything I could possibly find (computers, internet services, whatever) into one big zip file, and put it on my local NAS (which is backed up to the cloud). I don't think I'll ever have the heart to go through it again, but my brother had young kids who never really got to know their dad. I figure one day they might want to look at it (even if it's 30 years from now) so it makes me feel good to know that it's been preserved.
When my father in law passed away his wife asked me to get some photos on a thumb drive for her. I knew his password from watching him login, I also went ahead and deleted his browser history.
If you are perfectly prepared for your passing and made your will, arranged all the financial stuffs, told your friends and family everything needed etc. then you don't need to give access to your accounts. But many people don't have that luxury. When death is unexpected, things get messy, e.g you may want to continue paying the mortgage on time, or shutdown social media accounts, or make announcement of their passing using those accounts, or contact their lawyer, or cancel subscribed services, and so on.
While most people have focused on post-mortem account recovery, that's not the only occasion. The small company I've worked for has had the last three administrators leave the company in arrears for a time with quick departures and little handoff of procedures. It is all the more frustrating because we overtly use a shared password managment tool for accessing client servers.
When my dad died my mom needed access to all the accounts to do things like pay the electric bill. That is all done online so without him logging into the online bill pay she would have no way to know what was owed. I suppose after a few months of not paying they would send a paper bill, but then there are late fees and the like.
Doesn't work for all services. Some services will, if unable to charge the card,send whatever amount to collections, and now they have to deal with that.
You'd think it's that easy. Some places literally are unable to do anything unless you're some sort of "signatory" or the actual account holder. No amount of if, buts, maybes, and certified/stamped copies of death certificates will convince them.
I couldn't even cancel the health insurance company's recurring payments after a death. And they had the audacity to send a "how was your hospital stay" questionnaire to the account holder's email after they were "discharged" by the hospital.
> And they had the audacity to send a "how was your hospital stay" questionnaire to the account holder's email after they were "discharged" by the hospital.
That feels like an email that deserves an honest response:)
Its not just about passing away, even a sudden incapacitation from which you do recover may pose a bit of a challenge for the relatives:
Some time ago my dad had some severe heart problems which lead to him being hospitalised for multiple months and a lengthy recovery where he was in full "vegetable" mode in the beginning. As he is somewhat of a "patriarch" personality the whole family finances, insurances etc. where all on his personal system.
It really was "fun" to sort everything out for us and even more "fun" for himself making any sense of his whole accounting sheme after suffering some memory loss during the whole ordeal.
So... having some "letter of last resort" deposed somewhere may even benefit yourself...
that's what would scare me the most. to forget my passwords due to some accident. if i pass away it wouldn't matter to me, but the thought of recovering from an illness but then not being able to access things that i had before is horrifying.
I'm genuinely curious why this needs to be done. Maybe I'm weird, but I don't think I have anything valuable online that my family would want. Of course, there are all my financial accounts, but I would think that just a password wouldn't do them much good with those, at least to legally drain them. I would think (and could be wrong) they would need to go through legal channels for that. What else is there? I can't imagine they want download my email which is mostly just business transactions anyway.
I can think of a handful of things that it might be nice or convenient for someone to be able to access (subscription services and whatnot), but I agree that it seems legally unwise to encourage anyone to try to log into my financial accounts and move money around after I die. Naming a beneficiary is a sounder strategy.
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.
I'm with the other guy. Your unique pattern of electronic activity has ceased irrecoverably. No need for your patterns of electronic activity in computers to be any different.
Now that I think about it, I should probably do the same. I use Bitwarden and they allow you to add an 'emergency contact' that is granted access after X amount of days.
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.
Had the same experience with my dad passing recently, we had access to everything because we know the passwords he uses and he was ok with sharing those with us.
Will definitely look into the 1password emergency kit, thanks for mentioning it. 2fa is the other big challenge after that.
LastPass let you put two emails as your family members and you setup a 30 day limit to show you are alive. If your loved ones require access to your passwords and you are not there for 30 days, Lastpass release your passwords to them
I keep a hard card in my safe next to my property titles, and other important paper work that has my bitwarden master password on it. From there who ever processes my estate should have no problems accessing everything
I had a similar experience about 18 months ago when my friend A. suddenly died. He was fit and healthy, but for some reason had a seizure on a bike ride, crashed, and that was the end of his story.
Unfortunately for his widow, she and he were not on a family account with Apple, and so it took a LOT of rigmarole to even access, say, the photos on his phone.
Apple now has a "Legacy Contact" feature you can enable; this is a VERY VERY GOOD IDEA FOR MOST PEOPLE. I assume Google has something similar if you're on Android.
The tl;dr is really "you just gotta have a plan." When you go, next week or decades from now, it'll be hard for those you leave behind. Do whatever you can to make it easier for them.
"Software development is much more of a craft. A craftsman uses whatever tools he thinks will get the best result, no matter if they are what everybody else is using or something different. And a good craftsman makes his own tools when needed" -B. Moolenar.
As someone who had made vim is part of the development dna: Thank you.
Embodies the most amazing part about vim well. From text-objects to macros to registers, vim is a dynamic programming environment where we are capturing state and invoking little scripts.
Vim is spellcasting in the fly. Not puzzling out complex rotes to perform dutifully, but building a potent ether around us & then applying a little twist just so to alter the universe around us.
This is not a dig, just a concerned citizen: I would encourage you to check whether your microdose schedule has crept up from the standard 10-25µg into what looks like 50-75µg. It's one of those things that other people suspect long before you do. In any case, have fun, practice safe sorcery.
Best of luck, this transition period is going to be chaotic for a while I'm sure. Glad to see the project in the hands of someone who seems to be on top of things. I also appreciate the carefulness of changes to the codebase after assuming leadership.
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?
> what is it that outweighs all that neovim has to offer?
You should ask, and answer, the question in reverse. What does neovim offer me, as a regular vim user? I don't see anything particularly interesting for my usage, so I don't have any reason to change. Also, some features are missing (like gvim-gtk, that I enjoy using to edit LaTeX occasionally).
Furthermore, as of today, plain vim has an aura of venerability due to Bram's legacy that neovim cannot match. So I'll stick with vim.
It would make sense to port back some of the most popular neovim features into vim. It is a good thing to have innovative forks that experiment aggressively with new features.
> 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 anymore, but I know that neovim incorporated them first. If vim did follow on some of those innovations, consider how long it might take for new vim maintainers to get to a point where Bram needed to be to keep up, without his guidance.
I wonder if there is a need for both vim and neovim in the future. Neovim was born out of wanting to do similar things to what the vim maintainers are considering.
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 the new leadership will affect that.
it's not quite just a "better vimscript" language it's an incompatible language, if it was just improvement on top of the existing vimscript it would have been fine i think but what people are complaining about is if you are going to break compatibility why not choose an existing language like lua
Absolutely! I started using LunarVim packages+configs on top of neovim), looks like a couple of years ago according to my work notes, and the LSP has been a huge improvement in my editing.
Basically neovim can act as a client to a variety of different language servers (https://github.com/neovim/nvim-lspconfig/blob/master/doc/ser...) which give neovim IDE capabilities. This can be done in original Vim also but requires external plugins which can be a pain to compile and install. Neovim has it built in.
One of the big ones for me was Wayland support in neovim-gtk (https://github.com/Lyude/neovim-gtk), which therefore, unlike gvim, fully supports fractional scaling.
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 was using vimscript.
In Emacs the whole ecosystem is in eLisp, so I'd feel right at home there, could naturally integrate other eLisp codebases/projects, could easily get help on anything related to working with eLisp in emacs.
If I'd written scheme scripts in vim my work would always be a second-class citizen in the vim ecosystem.
How's the vim ecosystem now? Is vimscript still dominant?
> 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.
I use lua when examples are in lua or when I need some "logic" (such as assigning defaults to a var and then passing that around/overriding).
And that's embedded in vimscript.
I don't really like either. VimScript has always been a horror to me, eventhough I've been using vim for some 20 years now, almost exclusively. Lua is "that thing that I should really sit down and learn. But not now, I've got stuff to finish".
What does lua -for an end user- offer that something like yaml+python cannot offer? I really won't mind setting all sorts of flags, defaults and vars from some init.yaml, and then have some init.py to handle the few places where I do need actual logic. Why was lua picked, why did vim build its own language and not move to an existing one for its config? Am I just weird for never sitting down and learning lua? Or vimscript? Or both?
Lua is faster than Python and also easier to embed in vim [1] which are both big advantages for the end user. It means fast plugins and no hassle with having the correct python version.
Why Bram build is own language and then doubled down on it with vimscript9 I don't really understand.
> Why Bram built his own language [...] I don't really understand.
What language would have you chosen in 1991 instead of creating vimscript? The vimscript language is a very natural extension[0] of Bill Joy's "ex" language, that was used in vi since 1976. The history of vimscript is not weird, it's just a fairly natural continuation of existing practices. Vimscript9 is a least-friction update for modern times.
I should have written I don't really know anything about.
According to your link scripting was only available from '98, at which point Lua and Python were already around, but then I don't know how viable that would have been. Funny you say that about ex, because I find running ex commands from vimscript the most clunky thing about it.
In my opinion the least friction for the ecosystem would have been to follow neovim and adapt Lua.
independently of vim configuration, lua is a cute general-purpose language worth learning in itself. It is much simpler than python, and the documentation is outstanding.
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).
Neovim's adoption has been incredible. Virtually every major vimscript plugin has either been ported or overtaken by a Lua-native alternative in the Neovim ecosystem.
I think the ecosystem is more or less splitting. As a user, not dev, it looks like neovim "distributions" are mostly lua and would be feature complete (with some substituted plugins) even if 100% lua was enforced.
The Neovim people went a bit further with the integration, but you've been able to use Lua with Vim for like 20 years or so, and you can use it to write perfectly functional plugins with it. Probably the main difference is that in Neovim Lua is always guaranteed to be available, which isn't the case for Vim.
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.
> 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.
You're probably right. However, I think it's more likely that the Linux distros drop Vim entirely and make Nano the default editor than that they replace Vim with Neovim.
The BSDs have nvi as the default editor, IIRC, so they won't need to change anything.
At some point I tried to switch and some setting broke in my config (mouse mode?) I forget what it was. It took me another 3-4 years before I tried again.
My Vim needs are very modest. I just don’t need anything Neovim has. It’s complication I don’t need.
If Vim got no new features, I wouldn’t care. If Vim became unmaintained but still available from distributions, I’d still use it. If Vim became unavailable (e.g. due to lack of maintenance) I’d be more likely to switch to nvi than Neovim.
I could probably switch to nvi now, but I have no reason to.
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. Vim does want I need it to do. I don’t want it to change.
Neovim on the other hand exists entirely to change things. That’s all well and good. I just don’t want it. My editor is complete.
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
I did read your comment word for word: “Of course this means you'd rely on Neovim maintainers honoring that compatibility in future.”
I knew that maintaining compatibility was extremely important to Bram Moolenaar. I also knew that Neovim made a big deal out of removing “cruft” and old stuff they decided no one needed. I preferred Bram’s values.
and I responded to your "exists to change things". Vim also exists to change things, otherwise it wouldn't exist if Vi was enough. but it is compatible and from my experience nvim is compatible with vim.
Having to rely on them for that is a downside, but I guess you are free to fork nvim if they abandon that promise...
Loyalty? Inertia? I never felt like there was a reason to switch. I admired Bram’s work on Vim, still do, and didn’t see any benefits to switching. Still don’t, as long as the rest of the Vim dev community are willing and able to carry it forward.
For my purposes, Vim is complete. I don’t require new features, as long as it is maintained and runs on modern OSes.
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.
Give a real alternative to those instead of the many quarter-implemented GUI shells that are really no better than running Electron, and the switch might be able to happen.
Yes, if vim were unmaintained I would switch, that would be a reason to change. But it's not, or at very least hasn't been, so I haven't, that hasn't been a reason to.
> It's easier to maintain one codebase than to maintain two forks.
Not necessarily; if the two codebases are maintained by groups of people with incompatible ideas about how the code should work and what it should do, then keeping things separate is much easier.
> If development of vim dropped and neovim was nominated as its successor, I'd think most vim users would be just fine.
Agreed; they don't diverge that much from an end-user's perspective.
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.
Every time I've tried it, something was missing or broken. Currently it's at least :! which breaks apparently because it tries to do something ‘clever’ and complicated, whereas vi and vim just run the command.
(I can live without cscope, since I no longer do significant C and mlcscope has been dead for aeons, though it's shocking that LSPs are still less capable in some respects.)
not a heavy :! user, what i used there worked, but afaik neovim recommends :te . that's one of the bigger differences. neovim was very proud to have a fully integrated terminal
By now the two have diverged enough that switching configurations between both is an issue. Vim is still much more widely available (installed by default) than Neovim, which makes it the obvious choice to maintain your configurations for if you don’t specifically care about Neovim features. Furthermore, additions like Lua support, while pragmatic, make Neovim feel less organic to me.
In that vein, you are probably fine with whatever version of Vim is installed by your distro. But if you want LSP support for more cutting-edge stuff (like Rust), you probably need to install the latest release of Neovim by hand, not using the OS packaging system. Because stuff is changing too fast.
Can’t speak for everyone but in my day to day most systems I work with already come with vim preinstalled or more convenient to install than neovim. I’d rather just pull my vimrc (If I even have to) and get down to editing quickly.
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.
Likewise. I’m a heavy CLI user but gVim/MacVim are so entrenched in my workflow that the lack of a stable GUI for Neovim made it pretty much a nonstarter for me.
As some one who only uses vim/neovim in a terminal window - what’s the advantage of having GUI support in vim?
Mouse support in my terminal seems fine, even over ssh. Being able to do things like run it inside of a tmux session has always made it seem like the GUI would be a step back?
You can use gVim as a Notepad on steroids. You have the simplicity and familiarity of Notepad combined with the power vim, e.g. search & replace using regular expressions, syntax highlighting, the ability to delete 5 words by typing ESC d 5 w, plugins like fugitive and so on. I can't select text in neovim by pressing Shift and arrow keys. I can't copy text by pressing Ctrl+C.
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.
If neovim had the same keystrokes to move out of a terminal window as it does to move out of editor windows, I'd switch. But as it is, it's super clunky compared to vim.
I know about rebinding to alt, but that doesn't work in all my terminals.
So for me, it's that one lousy thing that keeps me from switching. And if someone knows the magic setting to make it mimic vim, please let me know.
I've never used those features, and instead rely on GNU screen (or `term`) to manage my terminal windows. Sometimes I also use horizontal / vertical splits with GNU screen, but it is a bit clunky.
I hear this and the workaround has been opening terminals in a floating window. The “toggleterm.nvim” plugin wraps a bunch of good behavior around this.
From what I've read[1], vim9script was pushed and developed almost exclusively by Bram. With him, a lot of knowledge about its internals and vision for its future dies.
You're correct it was very much a "Bram project", but that doesn't mean the language needs to die with him: other people can work on it (and already have!) Vim9Script is also "finished", more or less, as "finished" as languages get anyway. The features Yegappan mentions are what we might call "optional features".
If I look at some Lua plugins and compare that to some of my Vim9Script (or even "legacy VimScript") plugins then I think /Vim9?Script/ "wins" hands-down; it's just much more convenient for programming an editor. It also doesn't help that IMHO Lua isn't all that great of a language to start with – it's not horrible either, just not great.
On Windows gvim works loads better (even on Unix systems gvim is arguably better, because terminals kind of suck and you run in to loads of graphical and input limitations pretty quickly).
But in general: neovim doesn't offer me anything I want or need, I will have to spend time on migrating (e.g. my vimrc would error out, I need to deal with changed defaults, etc.), and for most things I prefer the "highly compatible" attitude from Vim/Bram, which is a trade-off that's not without its downsides, but I really like it (for most software).
Personally, I do heavy coding and writing in Neovim (with more extensive config, like LSP and Copilot), but I use macvim and gvim (depending on which OS I'm using) for quick edits or file viewing, because I often need to open files from Finder or Nautilus and I don't have a terminal open in that directory.
In my experience, Nvim and Vim are similar enough that I don't have any trouble SSHing into any server with Vim and using it after using Nvim all day for development. So far Nvim has been a purely opt-in experience for me.
I think "if the script worked before, I want it to work later" has much more practical weight. Though, on the other side of practicality, I've heard sed, awk, and perl suggested for manipulating text in bash scripts far more than I've heard of vi recommended for the task.
Yes. If you need to do some text manipulation in a shell script, `sed` or something like that is what I'd reach for first. (I haven't used `awk` or Perl for quite a while.) I'd think even `ed` would be a more straightforward choice than `vi`.
I would need to migrate my chunky config files. Some issues should be easy (moving files to ~/.config), some other trickier (vim-specific functionality).
But alas, the motivation is not big enough for me to invest the effort.
Some features I'd like from Neovim are built-in LSP (but Vim has that thank to plugins), and tree-sitter based syntax highlighting.
I would like to use Neovim, but it's not as fully featured as VSCode is, so when I need to boot up something more powerful than Vim, I go to VSCode instead.
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 would rather just use vi/vim for basic edits anyway.
I do use NeoVim with a lightly-customized LazyVim setup on my personal desktop, but I don't use it much differently than I use Vim at the moment. I'm not a power-user, just someone who's comfortable enough with the keybinds that I leave :w everywhere when using a non-vi editor.
> for some of us it's about what's the most minimal setup required to use the tool.
That's was the case for me. When I moved from vi to vim 25 years ago, I devoted a lot of time to customizing it for maximum developer efficiency. Around that time, I got a job where I regularly used five different HP/UX machines, a couple of Solaris boxes, and a few other random machines. At the next job, it was HP/UX, AIX, and IRIX. Few of those machines had vim at all, let alone a version compatible with the setup I had on Linux.
I eventually stopped doing the fancy things and settled into using plain vanilla vi, knowing that it would at least work consistently on every machine I used.
For me it's that Vim offers me enough to satisfy what I want out of a development experience and vim is also installed everywhere which means I can carry my setup around to pretty much any machine (including servers when doing remote administration).
Since Vim 8 launched with a built-in package manager I'm able to store my vimrc and any extensions in git and easily grab it on any new machine I'm on. The level of effort required for me to convert to Lua and adopt newer nvim version of plugins I use seems too high relative to the benefits.
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.
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..
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.
>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 refactor in the codebase.
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.
> 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.
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 too disruptive a change that would make Vim accessible on fewer platforms.
It’s brutal to say it, but often you handle it by some of the people involved passing away.
Even if neovim basically takes over the older vim code wouldn’t disappear, so it would continue to exist for older platforms. People still keep certain versions of GCC around for similar reasons.
async is water under the bridge since Vim 8, both Neovim and Vim have async apis. I foresee native LSP and everything-lua to be a bigger schism between Neovim and Vim.
Also the deliberate lack of GUI for neovim. The currently extant neovim GUI shells are all universally broken, and some of them crash more than they run. I have yet to find one that is remotely as good as MacVim on macOS. I suspect that most of them are merely tolerable on Linux and some might be barely acceptable on Windows.
With their recent release a few days ago, Neovide has become my daily driver for Neovim on my personal cpu. It were definitely rough edges a few versions ago, but I’m rather pleased where they are now.
I find a lot of Rust GUI projects are slow-going but this has had a good pace
I’ll try it again in a few months, because it was completely unusable on macOS last time I tried it in March. At the moment, I have no time for something that may not work when MacVim works pretty much perfectly for me.
I’ve tried so many different nvim GUIs, but when I last tried them (March or so), none of them behaved correctly on macOS, most of them had atrocious font rendering, didn't like part of the configuration that I had set up (neovide in particular had a deep incompatibility with one of the alert replacement plugins), crashed regularly, or had things enabled by default which aren't reachable with vim scripting.
I’ve gone all in and have converted my vim config to Lua and all…and I have decided that don't like Lua for configuration (there's a massive impedance mismatch between neovim and Lua; you always feel like you're working with a foreign interface).
Goneovim was slightly more stable, but IIRC, the font rendering and macOS integration were awful enough that I uninstalled it shortly after launching it. Neovide lasted slightly longer (so that I could see that plugin incompatibility). VimR tried, but it isn't MacVim.
And that's the problem: they aren't MacVim, providing a native macOS experience on top of a native vim GUI, because the neovim leadership cabal, in their infinite wisdom, decided that a first-party GUI is "useless".
> (there's a massive impedance mismatch between neovim and Lua; you always feel like you're working with a foreign interface).
I agree, and it's a bit surprising that it isn't talked about more. I still feel like it's overall a win compared to Vimscript, in terms of readability and maintainability, but there's definitely an enduring awkwardness to customizing the editor using Lua.
> Goneovim was slightly more stable, but IIRC, the font rendering and macOS integration were awful enough that I uninstalled it shortly after launching it.
That's fair enough - I used it on Linux, and I don't care too much about font rendering, so it works out for me.
Everyone puts off estate planning in general for obvious reasons (most people don’t want to think about their own mortality) all the more so, most don’t give a thought to digital estate planning, it’s especially hard because there are very few resources to do it and most apps/websites don’t have that workflow planned out (Afaik, really only Facebook does anything for this).
My wife and I share a password manager account so theoretically she should have access to every site I use, but will she know where to go? Will she have any clue how to maintain our local self hosted services? Let alone the hardware?
I’ve walked her through restarting the esxi server and ssh’ing into the main docker server to restart it, but I haven’t documented any of this anywhere for her…
I scrapped my self built server that runs snowflake TrueNAS with zfs doodads and replaced it with simple synology. It has mostly default settings with no encryption.
My wife has no idea about tech and I want it to be easy for her to access our digitised family media and documents, once I no longer around. Any tech literate people/shop can figure out how to pull data out of synology.
I never realized a tool I use every day was still being actively maintained. An endless amount of thanks to Bram Moolenaar, the many others that have contributed to it, and those that are now helping in the transition.
—-
As an aside, browsing this website on an iPad is terrible. It doesn’t respect my request to increase the font size, and when I zoom in, it starts moving and wrapping the text defeating the purpose of the zoom. That being said, the quote formatting and response is fantastic and how online communication should be.
I get the same on firefox with ublock origin, but it works if I turn off ublock or use chrome.
on my android firefox, I can't load any google properties - it just redirects to a help page about how to clear my cache (clearing the cache doesn't help)
I keep a couple of m-discs in my gun safe encrypted with a password most of my family knows, but they don't know the safe combination. If I kick the bucket they can cut the hinges off in a few minutes with my angle grinder. They could also use my corpse's finger to unlock my phone but that's a bit morbid.
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 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.
> Let's see how much traction Vimscript9 will get.
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.
> 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.
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.
If the project leads can agree to a shared vision - which frankly should be similar considering the scope of the projects - it's most likely better if they merge.
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 :-)
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/Neovim are already lacking in features to implement, bugs to fix, ways to extend their architectures :-)
The first three all have the same story though, where Oracle acquired the project, forced changes that drove the original authors out, who then forked the project and resumed development there. So Hudson/OpenOfice/MySQL essentially lost the key developers that had all the institutional knowledge, killing them.
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).
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.
There are also cases where the fork is caused by differences in philosophy and result in divergent codebases that are perfectly fine doing their own things, like NetBSD and OpenBSD.
MariaDB didn't "strangle off" MySQL. The latter is still significantly more popular (probably 10 times as much, if not more) if you look outside our HN/Linux bubble. It also had one of the best releases ever under Oracle's guidance back in 2018, many years after the split, when very few of the original developers were still at Oracle. Meanwhile, MariaDB development slowed down significantly over the past few years as they're having financial problems.
(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.)
Eh I'm not going to go through your list, but putting libre/open office on there is disingenuous. Open office was run into the ground by Oracle, not because of the forking.
Vim was developed by Bram commiting and controlling every change. Neovim very much already unlocked a greater than one situation by adopting a different development model.
No future for Vim without Bram? People said the same thing about Apple when Steve Jobs passed away. Turns out, as long as you have loyal users and competent people working, things can keep on chugging right along.
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.
I would not be so prompt to compare the situation with Apple and Jobs. Apple is a company that provides something no one else does while also holding a lock on its users. You can't go and install iOS apps on android.
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.
> On the other hand, vim and neovim are almost the same thing, and wherever they diverge, it is always to the detriment of vim.
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.
You've hit the nail on the head for me. From my point of view, vim is simpler than neovim. I value that and wouldn't like to see neovim subsume it (although I'm sure people are happy with neovim for very good reasons)
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 contributors had not wanted to work on vim they would not have been there in the first place.
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.
>No future for Vim without Bram? People said the same thing about Apple when Steve Jobs passed away.
Well, they were making a wrong prediction, but also a totally unrelated to the Vim/Bram situation comparison, then.
This is not the case of 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.
So, to keep the relevant parts of a comparison, this is an multi-person entity fully prepared for the demise of its leader, with people ready to take over, and stocked to the brims with the essential fuel to continue it's operation (cash), vs an entity that was essentially an one-man-show, with no preparations for the next day, and with a quite popular alternative ready to take over.
[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.
Time will tell, but I think vim is likely to fade away with slow development pace. People are all sentimental right now, but we'll see how many of them will remain in a couple of years still committing to vim daily.
Looking at the commit history, vim was largely a one-man show, I'm a bit skeptical about that changing basically overnight.
The commit history does not accurately reflect the contributions to the code-base. As I understand it, contributors would write and provide patches to Bram who would then commit the changes to the code-base.
From what I can tell the reason is that that’s the way it was always done. As I understand it, back in the days before there were distributed version control systems, Bram was the only one who could commit to the code-base so he would credit the actual author of a submitted patch in the commit message. He continued this practice after the Vim project moved to Mercurial (and Git).
> tons of hackers will want to contribute because it's cool
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.
> 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.
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.
>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.
>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 `:!` ?
> 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.
`: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.
> Why would you run an interactive command with `:!` ?
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.)
neovim supports OSC 52 out of the box so clipboard over SSH should just wrk in kitty or any terminal that supports OSC 52. kitty of course supports a lot more than OSC 52 but for basic opy/paste of plain text, OSC 52 is sufficient.
Try something that uses input, e.g. a pager (`:!git log`), or a password (`:!sudo something`), or `:!top`, or something with even the simplest formatted output (`:!watch -n1 lsusb`).
It works but I don't want to build the kernel to generate the compilation database every time I check out a new tag or branch. With BSD it would be even worse.
deepest sympathies for Bram and the VIM community.
reading the post it seems that the project will continue after some growing pains from the lead. one thing to take from this is projects as popular as VIM need to hand the keys to the kingdom over to the community before anything drastic happens.
Shaking up the community right now would probably make efforts to continue Vim’s development more challenging, and make it more likely remaining contributors switch over to Neovim.
Google groups I can't comment but Github is a relative new thing. They were also still accepting patches on the mailing list(I believe the github pull request were mirrored to the ml or something like that). Bram was often replying to issues and pull request via email so github adoption doesn't seem to what Bram wanted. So no migration away from github.
Why so many people love vim? I have a genuine question. I was trying to delete contents of a file and paste new content. It was nightmare for me to remember the 3 or 4 finger combination shortcuts with small and cap letters involved during the process. I like if the shortcuts using Ctrl or shift or Alt or Command or Windows buttons over 3 finger with caps changing keys. The cognitive load in remembering shortcuts is nightmare. Please give me a genuine opinion and justification. Does it really makes someone that productive? If they are keyboard wizards to type faster can't they do even faster with modern ides with similar proficiency. I know this topic is near and dear to many. Especially, the creator is died and folks can get even emotional. But I have same complaints about any terminal based ides. I just don't get complex long form keyboard shortcuts!
Vim is a nightmare if you don't use it very often. Moving around a text editor with a keyboard feels extremely strange coming from a traditional text editor or IDE.
However, once you get used to it, it's absolutely amazing. You can move as fast as your thoughts, sometimes faster.
I forced myself to use Vim for two weeks after having been a long-time eMacs user (and Notepad++ prior to that). Those two weeks were hell. I felt like a baby learning how to walk.
It felt like second nature a few months later, and any editor that didn't have keybindings felt primitive a few months after that.
Very simply - Vim is a program that you are required to be a "poweruser" of to make work. You NEED to know most keypresses and shortcuts ( at some point, Vim is a language that you're speaking to the text you're editing ). This is not the case with most software - but find anyone that is a poweruser of any software and they'll love it to death.
Because most things can be done 10 different and equivalent ways, you develop your own personal way of interacting with it, and it's "personalised" to your workflow - not by design, but because you won't remember things you don't use/understand.
Learning Vim shows you to rely on yourself and to persevere, and if you do it you are likely to stick with it. Just like Emacs!
If you use vim every day, the common operations become muscle memory, I don't even think about jumping through the file, find and replace, block edits etc, they just happen.
For me personally, the context in which I edit files changes constantly - sometimes it's inside a Docker container, sometimes it's on a server, sometimes it's on my personal Linux machine, sometimes on my work Mac... Vim is easily available on all of those, and I just use the default configuration.
I do see my colleagues benefit from VSCode. If my work environment was very consistent (same computer, same language) I think you're right that I would possibly gain in productivity from using VSCode (with Github Copilot, perhaps). But my work environment is not consistent, so Vim it is.
The point is you don't remember them, they become second nature, intuition, and you just sort of... do it without thinking. Assuming you've given time to learn it, editing with vim takes less mental effort and is faster.
I don't have a paper I can cite you, however if you talk to vim users most will tell you they feel more efficient and less friction compared to "normal" way of editing code. There's a reason this program is so popular and there are vim keybindings for any popular editor, after all.
As a vim user, I am 100% convinced that I am not that much faster than my colleagues who use normal key binds. However, I subjectively feel a lot less friction editing with vim keys than I do with the mouse and arrow keys. So Vim makes me happier...
This is the way I look at it. The productivity claims are probably a bit overhyped. For me Vim is just simply fun! It makes me think of the best way to do something, and there is always something new to learn. It makes me happy as well :)
While your perspective is totally valid, I think the idea that you always have to think about and learn how to use your editor seems to confirm the original commenter's point about the whole thing being too complicated.
To which I say, I've been using Vim (and nVim) for more than 20 years now, and the learning part is optional after a year or so of intense use.
Same thing. Not sure why everyone is obsessed with the speed argument. Reducing cognitive load is the goal. How do you do that - with vim or something else like snippets or copilot or just muscle-memorying ctrl/shift-arrow motion is up to you.
Asking why people prefer vim is like asking why they prefer skateboard over rollers. You’re proficient at what you learned the most. The only thing you have to keep in mind is that every tool has its limits, so choose what you’re going learn from that perspective as well.
What source can he give you? It's clearly a personal annecdote that is shared between a lot of people that use vim. What kind of source are you thinking about?
Not saying that this is a good study - I haven't even read it. Merely providing it as an example that at some point a study has been made in this area.
I'm not saying that you can't do it, you obviously can. It's just weird asking for studies for something that was clearly a personal annecdote. It's like asking someone: "Which knife is your favorite knife?" getting an answer and asking for a study that validates the answer.
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 home position. The time saved from physically moving your hands to and from various keyboard/mouse positions are reduced. At least Vim can be faster in that sense.
You're saying you have a personal anecdote about a coworker (who from your description isn't necessarily using Vim). 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.
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.
> "It would be nice to read some actual study showing this to be true"
https://danluu.com/keyboard-v-mouse/ - concludes that it varies by situation; keyboard wins at tasks where you might expect keyboard to win, mouse wins at tasks where you might expect mouse to win, tools like regex search/replace wins at tasks where you might expect it to win.
It’s unclear how I got there. It was long ago but my guess is two key things: I believed in rumors/stories and I didn’t give up.
Tbh, if vim wasn’t vi-like, I’d still use it for its programmability. <- This is the main point beyond learning curve. Maybe I’d like emacs too, if I learned it. Or other modern editor. I’d even use vscode as it looks nicer and has many widgets, if only it wasn’t such pain in the ass to program and/or tune up to your taste.
I’m certain that everyone has to use what fits their personality.
(Added: not concerned with speed or whatever unless an editor starts choking or popping up interfering crap randomly. I use mouse when it’s convenient and mostly move with arrows except for AIO^$ - I don’t have homerow discipline anyway.)
I know this topic is near and dear to many
Not at all for me. Vim is not everywhere and when I have to take a quick note or copy-paste I often open Notepad2 (because I don’t want to switch between editing models). I just prefer vim model when it comes to long/structured editing sessions.
Btw, did you know that ctrl/shift-arrow editors are also different? This also has something to do with my vim preference.
When you use it, either in a text field or in an editor, there’s a little uncertainty where ctrl-stops are and how the cursor behaves regarding EOL. Is symbol/char a ctrl boundary? Does it jump forwards at the same positions like backwards? If I move up to a shorter line, will it retain a column index and an EOL flag? If I <End>, does it have EOL flag at all? Which way do you select whole lines? Home shift-down? Home home shift-down? Ctrl-L? You want to select whole lines to not deal with extra indent on paste. Or does an editor fix that?
There are lots of editors that behave differently. Almost all of them.
What bug me in it, is that you now have to wait for ctrl-arrow to finish somewhere, but you don’t know where. So, combined with a high repeat rate (which you want unless you like watching a snail to run or paint to dry) it becomes a release-timely game. I definitely remember struggling with that when I still used windows-style editors.
It would be not an issue if I chose one and used it. But they die or get ancient wrt useful plugins so quickly. Norton, borland, ulti-something, notepad++, various IDEs, linux zoo, sublime, atom, vscode. There’s no end to it. One decade and it’s either “obsolete” or requires a high-end ssd to just start.
I think this explains it very well https://learnvim.irian.to/basics/vim_grammar. You stop thinking about doing specific things tied to a specific keymap and you start to interact with your code using vim's grammar. Besides that, its nice having a consistent keymap between the different IDEs, text editor, browser and shell.
Personally I hate if theres a keymap that uses more than a two keys at the same time and I much prefer having a sequence of keystrokes like vim does, I do touch typing so it's natural for me to type a sequence, but if you introduce any modifier key I have to move my fingers from their position.
Also, you can find vim in most unix machines that you are going to interact with.
Vim's major benefit is that commands are composable. For example, `d` means delete -- but delete what? Well, that's based on the motion command you supply, from lines, to the end of the file, or even looking for a specific character.
Edit: Another benefit: vim works very well over all sorts of connections, even ones that do not support the full set of Control/Shift/etc. For some of us, this is very handy. (Also, vi, the ancestral editor to vim, is very small and often available in environments other editors do not fit into -- and the commands are much the same.)
Most "complex long form shortcuts" that Vim use are one or two keystrokes. Add an extra Escape key for switching between insert and command mode.
The "normal" Ctrl/Shift/Alt/Command/Meta shortcuts are two keystrokes as well.
I think it's a matter of preference and habit. I like not having to move my hands away from the home position of the keyboard when I'm intensely typing. Perhaps some people have much greater accuracy than I do when (for example) moving their hands to press the the arrow keys and then returning to the home position. For me, that distracts me a tiny bit having to spend brain cycles to check whether my hands are in the right spot.
Just sharing a personal anecdote.
Oh btw, why do so many people "love" Vim? It's been around for decades. I'm pretty sure unless you use Emacs, you've changed your main text editor over time. The most popular one today, VS Code, didn't exist a couple years ago. Not sure what people used before that, but IIRC no mainstream text editor was around for so long, on so many different platforms, and in such a consistent manner.
Vim has been around for 30+ years, and I've personally been using Vim for 20+. It's easy to be attached to something if it has been around for so long, and so consistently.
And also, sometimes, maybe, when a creator pours love into a product, the users can feel it. Maybe.
> I was trying to delete contents of a file and paste new content. It was nightmare for me to remember the 3 or 4 finger combination shortcuts with small and cap letters involved during the process.
Vim rarely uses multi key combinations like emacs or most other editors do. Copying and pasting involves some knowledge of how the copy registers work. It can feel confusing when you first try it, but you figure it out eventually...
> Please give me a genuine opinion and justification. Does it really makes someone that productive?
The best way I can explain this is that vim is language. The process of editing in vim involves speaking this language. And once you're used to it, this language itself helps you reason about and execute editing tasks faster. It's also faster because the commands are very concise, and imo pretty easy to remember because they are mnemonics for the operations they perform. Imagine a task like selecting a string in quotes and changing it to something else with a mouse. In vim that's <ci">. c(hange)i(nside)"(doublequotes). Performing this is as instant as having thought about it.
The cognitive load of using vim is the same you have while riding a bicycle, or while typing with ten fingers on the keyboard.
After you get used, it's very easy.
You just need to study or to play with it, e.g. with https://vim-adventures.com/ !
Why do you love the way you do it? You're used to it. vim users don't have a cognitive load because 99% of them learned vim at the same time as learning programming. Is it worth it in 2023 to learn if you're used to a standard input method? Probably not, the majority of complexity in most people's job takes place in the mind and saving even a hour a day is likely not worth it - consider that even if there is no added cognitive load with vim, the fact that you can input faster means you're moving faster which can be exhausting. I for one, like the menial aspect of typing as a way of taking a break from everything.
If you install graphical Vim (gvim) on Windows, I think the installer offers to remap Ctrl-c and Ctrl-v to copy and paste. You also get the standard GUI menu bar at the top with Edit -> Select All, Edit -> Copy, Edit -> Paste which you can click on.
It's a good thing to plan for this eventuality, to make it easy for your family and friends to wind up your "digital life" after you've passed. 1Password has a very good solution for this, with a "recovery document" you can print out and write down your password on, which contains instructions anyone else would need to access your 1Password account. I gave a copy of this document printed out to a small number of people I trust implicitly.
You never know when something sudden can happen to you. For the sake of those you leave behind, it's a nice gift to plan for this eventuality, even if it seems far off at the moment.