Earlier quoted context omitted.
There’s no future to Vim without Bram. A merge of the two fork’s isn’t what Bram has wanted, but it’s the best way to keep Vim alive
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 Future of the Vim Project
291–300 of 376 posts
Re: The Future of the Vim Project
#292I'm saddened by the news. 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.
Re: The Future of the Vim Project
#293Earlier quoted context omitted.
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 wa…
> 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?
Re: The Future of the Vim Project
#294What 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?
$ rpm -qi neovim package neovim is not installed $ dnf search neovim No matches. I don't have anything against it, but prefer being able to use the same tool across environments.
> 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...
Re: The Future of the Vim Project
#295Earlier quoted context omitted.
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.
Step 1: Kidnap $target Step 2: keep for N+1 days Step 3: …* Step 4: profit! * where “…” just means “wait”
Re: The Future of the Vim Project
#296Earlier quoted context omitted.
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.
Step 1: Kidnap $target Step 2: keep for N+1 days Step 3: …* Step 4: profit! * where “…” just means “wait”
Re: The Future of the Vim Project
#297My brother passed away very suddenly a few years ago, and I was put in charge of wrapping up and archiving his "digital" life. We were very lucky that we had access to a recovery email for his main gmail account (as well as a couple of passwords that his partner knew) and was able to access and archive virtually all data we could think of (services like Google Takeout were invaluable). I realized that if this had hap…
I’m sorry to hear about your brother. > 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…
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.
Re: The Future of the Vim Project
#298Earlier quoted context omitted.
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/Neo…
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…
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).
Re: The Future of the Vim Project
#299Earlier quoted context omitted.
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.
Re: The Future of the Vim Project
#300What 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?
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.)