The Future of the Vim Project
groups.google.com
groups.google.com
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.
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”.
So that could potentially be (at least) three different financially-related accounts.
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.
Other banks allow the same thing via virtual accounts.
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.
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.
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.
There are a few of these, one official one for notifying the government and a few private ones.
I imagine this services exists in other countries, if not then might an opportunity to create it.
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.
making a budget is useful, as is tracking your expenses, but that's about it for me.
Will definitely look into the 1password emergency kit, thanks for mentioning it. 2fa is the other big challenge after that.
I’ll definitely go through the steps, but I’m wondering what the best way to store it is. Feels weird keeping a document lying around giving access to all your passwords, bank cards, finances etc.
I’ll have a think about storage.
There are people out there with 1password and no recovery kit ? Some people like to live dangerously
If you have a lawyer/attorney that you trust they’re often in the habit of securely storing physical documents, but again, expensive.
Personally, I (a cheap-ass) keep a copy in a wooden box buried underground in a secure location along with a few other things.
However, the security of physical things remains a difficult problem that is most easily solved with money!
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.
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.
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.
My parents simply made a list of passwords on a piece of paper, buried with the other important papers.
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.
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.
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.
That feels like an email that deserves an honest response:)
In social media world, posting some final "xyz has passed on. this account will be closing" or similar 'wrap up' activity is often useful.
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.
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.
Also, unless your arbitrary number of friends are cryptographers, it's a sure way for them to collectively lose your shit.
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.
Google Apps strikes again...
Step 2: keep for N+1 days
Step 3: …*
Step 4: profit!
* where “…” just means “wait”
You can have 2-of-20 which encrypts an encrypted blob whose key you share in your will
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
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.
You might not die, but you might still end up in a pretty bad position: https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my...
Incredibly unlikely, of course, but you'll certainly feel like a dick if it does happen.
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.
You can buy a piece of 100x50x3 mm 316 stainless steel (thats 4"x2"x1/8" in freedom units) for around $5.
Engraving it is a simple matter of using a $10 automatic center punch and write the password out in dot punched letters.
If necessary, cut plate in N pieces with a hack saw, distribute among N people.
I always mark bicycles this way, dot punch my last name underneath the bottom bracket shell.
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
* What to Do Before You Die: A Tech Checklist – https://archive.is/6vjqQ
* Cheat Sheet For If I'm Gone – https://archive.is/lnWX6 –https://github.com/christophercalm/if-im-gone/blob/main/exam... (HN discussion: https://news.ycombinator.com/item?id=31748553)
I've been thinking about building a platform to help prepare for and guide families who are faced with this kind of situation.
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 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 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.
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...
> 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
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.
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 strongly second the imperative to preserve as much as possible in the event that any of us suffer a mischief.
EDIT: The Internet Archive has a functional copy. https://web.archive.org/web/20230810094255/groups.google.com...
Required reading: https://evrone.com/blog/bram-moolenaar-interview
"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.
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.
nvim --clean --startuptime /tmp/neovim
003.174 000.001: --- NVIM STARTED ---
vim --clean --startuptime /tmp/vim
004.274 000.001: --- VIM STARTED ---
I abbreviated the output, if you run the above command and check the file, at the top it says
times in msecSuch 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.
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.
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.
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.
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?
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?
Why Bram build is own language and then doubled down on it with vimscript9 I don't really understand.
[1] https://neovim.discourse.group/t/why-was-lua-chosen-for-neov...
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.
[0] https://en.wikipedia.org/wiki/Vim_(text_editor)#Vim_script
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.
[0]: a Lisp that compiles to Lua, https://github.com/bakpakin/Fennel
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.
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.
However, this was Bram's vision. We don't know how the new leadership will affect that.
Great point. I wasn't following vim much, so didn't know the context around the language changes.
That does seem like a core philosophical difference. I'm interested to see what the future holds.
- Different servers may have different versions of the program. Some distros are very "stable" and have very old versions of programs.
- It's common (especially for vim) for users to have significant configuration files to make use easier.
If development of vim dropped and neovim was nominated as its successor, I'd think most vim users would be just fine.
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.
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.
vi is part of POSIX. That alone would be a reason to mantain Vim as a modern superset of vi.
It’s a basic infrastructure that you don’t want to break.
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.
I copied .vimrc to .config/nvim/init.vim, did a :PluginInstall and was up and running.
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?
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.
- Features I find useful have been removed.
- I dislike Lua, and significantly prefer Vim9Script.
- Gvim is useful at times.
> Features I find useful have been removed.
Which ones specifically?
> significantly other Vim9Script
What do you like more in Vim9Script?
> Gvim is useful at times.
What are your use cases for the GUI?
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).
I don't want to type like it's 1976. I want something simple and easy to use similar Notepad / gedit, but that still powerful when needed.
[1]: https://github.com/vim/vim/discussions/12736#discussioncomme...
For my purposes, Vim is complete. I don’t require new features, as long as it is maintained and runs on modern OSes.
(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.)
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.
That's not enough for me to move to Neovim.
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.
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.
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.
Having to rely on them for that is a downside, but I guess you are free to fork nvim if they abandon that promise...
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.
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.
$ rpm -qi neovim
package neovim is not installed
$ dnf search neovim
No matches.
> Neovim is available through EPEL (Extra Packages for Enterprise Linux)
from https://github.com/neovim/neovim/wiki/Installing-Neovim#cent...
> Neovim is in Fedora starting with Fedora 25 > sudo dnf install -y neovim python3-neovim
from https://github.com/neovim/neovim/wiki/Installing-Neovim#fedo...
Best of both worlds.
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.
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.
Even if the fork doesn't heal, if they could align the code bases to bring them closer, both sides win.
Edit: Looks like I'm wrong about neovim not being a fork of vim.
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.
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.
Or you abuse the preprocessor and automake.
I find a lot of Rust GUI projects are slow-going but this has had a good pace
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".
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.
A bigger blocker to a merge/collaboration would be the move to use Lua in neovim
> Neovim is a project that seeks to aggressively refactor Vim source code
> It is important to emphasize that this is not a project to rewrite Vim from scratch
> 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.
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 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.
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.
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…
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.
—-
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.
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)
So yes, maybe the servers handling google groups are a little too busy.
RIP Bram, I learned a lot from you.
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.
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.
Vim is a marquee project, tons of hackers will want to contribute because it's cool or because they want to have that name on their CV.
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.
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.
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.
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.
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.
Bram, for 98% of the commits/lines, plus some statistical noise.
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.
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.
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.
Looking at the commit history, vim was largely a one-man show, I'm a bit skeptical about that changing basically overnight.
Related discussion: https://github.com/vim/vim/issues/1554
“Taken at face value by most modern users of Git, the commit history does not accurately reflect the contributions to the code-base”.
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 :-)
You and meitham are very focused on this, but it is very much an opinion and not a fact.
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 :-)
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).
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.
(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.)
It is fact that 1 + 1 > 1 if you compare available resources.
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.
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.
> I would rather expect a EGCS/GCC "merger"
Or libav vs ffmpeg.
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.
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.
What's wrong with all features enabled by default?
> I'm sure neovim dropped a lot but I don't have the full overview.
https://neovim.io/doc/user/vim_diff.html
>Prominently it dropped support for giving !commands access to the actual tty. Commands that access the tty have to be used through the command :term instead.
Why would you run an interactive command with `:!` ?
And about !, It's also listed as a thing that changed, no judgment. Regarding usecases I think if it's possible, some user will take advantage of it.
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.)
It’s easy to implement OSC 52 copy with a simple script/plugin, but apparently not paste without adding some code inside of Neovim itself.
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.
The closest neovim equivalent I can think of is :term <command>
The resulting feature set was closer to VS Code than Vi. If that’s “slow”, it was still so fast it felt instant.
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.
Thank you very much.
> Something went wrong. Please try again later.
Edit: typo
I had a coworker who swore that X was the fastest way to do Y. Turned out it wasn't and X just made him very busy hitting keyboard quickly.
Are you saying that studying how efficient various text editors are for some groups of people is not possible?
Here's what I believe to be an example of some study on how text editors compare:
https://mjambon.github.io/vim-vs-emacs/
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.
> Assuming you've given time to learn it, editing with vim takes less mental effort and is faster.
What gave away that it was a personal anecdote? I interpreted the "you" part as if he was speaking generally about other people and not only himself
In my main language, we would have written something like below if it was a personal anecdote (rough direct translation):
> I was able to edit faster using Vim after taking the time to learn it.
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.
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.
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.
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.
The cognitive load is no greater than it is to remember that Ctrl+C is copy and Ctrl+V is paste. Once you learn them, you don't think about them.
Perhaps a better discussion: https://ferd.ca/vim-and-composability.html
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.)
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.
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!
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.
While I'm a heavy vim user myself, I'm not sure if it really makes me more productive. But it is more fun to me than, e.g. working with VS Code.
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.
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.
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.
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.