Vim Boss
neovim.io
neovim.io
I've been using Vim (and sometimes more recently Neovim) for over 30 years (nearly every work day of my entire career), having used `vi` on various BSD systems in school. In all that time, I've never been on the mailing list for Vim, asked a question or submitted a bug report. I've never needed to do so. Because I've never run into a bug or had a question that couldn't be answered by the built in documentation.
A quality software project, lead by a quality man. You've been an inspiration.
I’ve also worked on relatively simple systems that have required more interrogation due to a lack of, or in one case absolutely terrible documentation.
Reading the comments here, it seems that the hacker's mentality still lives on. The new young billion-dollar company will be replaced in another 10-20 years. Vim lives on. I wish to build a Vim of my own one day.
Maybe it's better to say the tool has sharp edges that if you aren't familiar with it, can bite you. But with a bit of practise and some knowledge you can master it.
Restart your computer if all else fails
The beginning screen of vim tells you how to exit.
If you do C-c, as normally is the case with TUI programs, Vim also tells you how to leave.
The "I don't know how to exit Vim" is a bit overplayed.
Of course it is possible that one might not think of using ctrl+c, but that's lacking general shell knowledge, not vim knowledge.
Thanks Bram.
> Sad
> Perhaps all these things add up to why it hit me when I read the news that Bram had passed away. In the message, his family made it clear that Bram was ill (‘a medical condition that progressed quickly over the last few weeks‘). This was unknown to most people and made the news all the more surprising.
> And it made me even sadder when someone pointed out Bram’s recent GitHub activity.
[0] https://j11g.com/2023/08/07/the-legacy-of-bram-moolenaar/
EDIT: From BDFL list in Wikipedia Bram seems to be the first to be marked as †.
Either this was super coincidence, or someone at the NS (the Dutch train company) is a vim fan and payed tribute to Bram like this.
Video in Dutch: https://www.youtube.com/watch?v=JPvh9SaQbUY
They're meant to be felt by index fingers.
I didn't care about them on my old QWERTY because I wasn't touch typing correctly, now I understand why the indentations are there.
Video in Dutch: https://www.youtube.com/watch?v=JPvh9SaQbUY
We didn't hire the guy. It's interesting seeing these memorials for Bram, from what people say he was the polar opposite of this kid in a good way.
The kid enters a security related conversation and Bram not only listens but engages in the conversation. Seems like you missed on a great hire.
They're not particularly difficult challenges, just things to see how a candidate approaches a problem. I don't remember what exactly was disconcerting about his approach but I feel like he took a lot of short cuts via google searching and didn't exactly understand what he was doing. This was years ago back when we did in-person interviews though, so my memory isn't 100% on it.
We have a lot of extremely intelligent people with small egos at my company and cockyness like that doesn't really fit super well with our group.
I was with Bram though! It was never meant to be secure in a cryptographic sense...
This can even mean someone's loss of life in the right (meaning wrong) regime, or property (e.g. storing bitcoin info there).
It's like advertising a "self-driving technology" when your car needs human supervision to not crash and kill you or someone you fall into.
The mistake you are referring to is someone that assumes "encrypted" means three letter agency safe, which is a pretty terrible way to leverage encryption. In that case, it's exactly like hopping in a Tesla and assuming auto pilot will take you home without your supervision.
That's not a mistake, that's table stakes. People reading that X offers "encryption", should assume its cryptographically safe to the standards of the day, and be given that.
Not just some "safe from your spouse, ...maybe..." glorified rot13.
Else, just don't offer it. It's not Vim's place to offer "file encryption" anyway, especially if they can't keep that promise. It's fine not to offer it.
And it doesn't have to be a "three letter agency" that's the threat. The "angry ex-girlfriend" could might as well be a programmer. Or have a script-kiddie nephew. Or know a person or two who can use off-the-shelf tools to decrypt it. And the file might have things like a person's bank account passwords.
Thus, the GF V. FBI scenario. Just because you "encrypt" something doesn't make it '100% Safe'. Such as someone keylogging you for your onepass pass.
[0] https://www.washingtonpost.com/graphics/2020/world/national-...
I've been impressed with how Bram's passing has been handled by his family and friends with respect to his legacy and the future of vim.
https://j11g.com/2023/08/07/the-legacy-of-bram-moolenaar/
By Jan van den Berg, was a better read. One quote:
"Vim is a masterpiece, the gleaming precise machining tool from which so much of modernity was crafted".
And then this link:
https://m.youtube.com/watch?v=eX9m3g5J-XA
"7 Habits for Effective Text Editing 2.0"
1h20m - If anyone has a transcript or summary: plz. But this was funny - first comment:
"I let auto play go on while I was sleeping for 7 hours and went from Billie Eilish to this"
Life is weird but I love it :-)
Disclaimer: I'm not even user of either (Neo)vim or Emacs. As soon as I read "programmable", I'm off. I just prefer fixed-function editor that suits my taste , a few minutes of configuration & go. But that's just me, what do I know?
That said: good tools serve a purpose. Our world is a better place with good tools in it - and the ppl who made those tools. And sometimes their legacy, their philosophy, their way of doing things, lives on in the code (or the community!) they left behind. So kudoz to Bram!
Then Helix may be for you! It uses the Kakoune keybinds, which make SO MUCH SENSE compared to Vim or Emacs. And it's already pre configured and includes a lot of useful features. I have been daily driving it and it's pretty fast and good. Since it automatically uses LSPs if they are in the PATH, it requires very minimal configuration, my configuration only includes theme and some stylistic changes, you can take a look at it if you'd like: https://github.com/RGBCube/NixOSConfiguration/blob/master/ma...
[1] https://github.com/nvim-treesitter/nvim-treesitter-textobjec...
There's something to be said for having it baked in though. I've been nix-ifying my configs and not having to think about any plugins was a welcome change.
(Unless you count language servers as plugins, which you maybe should.)
>1h20m - If anyone has a transcript or summary: plz. But this was funny - first comment:
Here you go: https://moolenaar.net/habits_2007.pdf
Courtesy of tlamponi [1]:
I never have to "program" Vim apart from set nocompatible, set ruler, backspace, indentation and maybe pick another colorscheme from the defaults (usually torte).
On neovim I installed lightline and pathogen, monokai colorscheme and something else I forgot about, maybe syntax highlighting for some more exotic language.
The point is Vim is a fixed function editor until you start loading it up like a xmas tree.
Exactly, just because you can doesn't mean you need to, or should.
set nocompatible
set backspace=2
set noexpandtab copyindent preserveindent softtabstop=0 tabstop=4 shiftwidth=4
set ruler
colorscheme torte
Neovim's init file has this plus more stuff to turn off features like showmode, keybinding for nohlsearch, SQL autocomplete and space indentation for python. Maybe some of those annoying defaults are set up by one of the plugins. It's loaded with up with three plugins: lightline, vim-polyglot and vim-visual-multi which I forgot how to use and wonder why it was loaded in the first place. Polyglot is loaded because I needed syntax highlighting for some more exotic language like Crystal, D, Dart or TOML. Apart from that it uses the monokai-tasty colorscheme. So basically this is my setup. If I open anything in vim that doesn't have syntax highlighting and I find it annoying, I would just close the file and open it in nvim instead. I think Polyglot also helps with Racket.
I've also tried helix and kakoune but find the popup menus quite annoying. Also not being able to set the indent width in helix except on a language basis is a total turn off.
I got used to typing vi instead. It's shorter
alias vi=vim
alias vi=nvimhttps://manpages.debian.org/bookworm/dpkg/update-alternative...
I just want vim to be aliased to it though, since if I type vi I want something very light and quick (my nvim is bloated ;)
> map <F5> <Esc> :perl use Text::FindIndent;VIM::DoCommand($_) for Text::FindIndent->to_vim_commands(join "\n", $curbuf->Get(1..$curbuf->Count()));<CR>
Text::FindIndent is the aforementioned heuristic as a Perl module. Sorry for the mangled quote, original at https://metacpan.org/pod/Text::FindIndent
When I work on existing code, I hit F5 and work within the author's preferences.
Thank you for posting this. Rest in peace, friend.
It's one of those things I always suggest to new programmers. Learning Vim may arguably have a steep learning curve, but it will open your eyes to a different and more efficient way of interacting with text, which is something you constantly do as a programmer.
I've enabled Vi(m) mode everywhere it's supported: from shells and everything that uses Readline, to making it the default in Emacs via evil-mode.
The modal interface and mnemonic commands that can be combined in different ways is a far superior and more intuitive UI than the Emacs key chord UI. I love Vim. It's what got me started on this journey 20+ years ago. I still use it daily for quick edits, but prefer Emacs as an IDE, as it's a more extensible environment. With evil-mode, I get the best of both worlds. :)
Bram has improved so many of our lives, and deserves to be recognized among the all time greats in our industry. RIP.
I only wish I had the opportunity to thank Bram for the impact he's had on my life and career, because I don't think I would have come as far without Vim.
There are some though that really do live up to the postmortem messages and for sure Bram is one of them, i was lucky to meet him and actually spend some time shooting shit with him. At the time i didn't realize how big a deal he was, it was only later i would actually get to know and appreciate VIM, but from all of that it made me appreciate him a lot more. So when I read these kind of posts i can't help feel sad of course but I do get shivers of how damn ossum he really was. The testimonials to him hit so hard knowing they're 100% genuine. We need more like him, he will be really missed.
No one can really be sure how their acquaintances feel about them. Eulogies are the closest we get. Imagine if he were able to hear all these great things said about him... It would be such a joy.
It's only today that I am forced to think about this: One person drove that program from an idea in their head to a high-quality, hackable program that I've fallen in love with over the years! A program that I have used for so many hours, but has never crashed once (neovim does crash, but vim has never done this for me.) This is an impressive feat given the sheer volume of vim plugins and configurations I've gone through!
Thank you Bram! You built an amazing program and the community around it!
Link to the talk: https://www.youtube.com/watch?v=p6K4iIMlouI
I don't understand this point, and I tried to parse it and still don't. (I understand that you are just relaying it).
If vim maintainers don't want neovim to exist, they should have accepted the merges earlier. If they disagree with the merges (which I think they did), then that power doesn't belong in Vim anyways.
edit: this reminds me of this conversation from years ago
https://news.ycombinator.com/item?id=14245705
Check DSMan195276's comments.
And finally before I derail, I want to bring stuff back to the focus: RIP Braam.
It's a very simple point to understand: whether the merges are good or not, the presence of a fork still "splits the Vim community and takes people power away from Vim development".
And if they're bad (which is the way they see it), they do it for no good reason too.
That's regardless of people "having the right to fork". Yes they do. But also yes, if they exercize that right, they do split a community and divert interest from a project to 2 projects.
If Neovim had nothing to offer vs vanilla Vim, nobody would have followed them. This seems like efficient exploration of an idea space, to me, and something to be celebrated.
You're not dividing the same-sized pie.
The alternative to a fork is a single project with fewer contributors.
The alternative to two communities is a single community that's not as large as the two would've been, with a good chunk of those remaining having unfulfilled wishes or unheard complaints.
The alternative to Vim as it is today is very likely Vim without a a few of its new features and improvements that came with Vim 8 and 9.
Forks are good.
We do. Neither vim-or-vim-fork editor users nor vim-or-vim-fork-potential-devs are going to see any significant jump in population from the presense of neovim. People who are new to vim-style-editors and go to neovim are mainly people who would have gone to vim if neovim didn't exist.
And from people contributing to vim via themes, plugins, etc., some have taken their talents to neovim, which would have stayed with vim if neovim didn't exist.
>Forks are good
Well, the prevalent wisdom of 30+ years of FOSS has been that they're mostly bad.
> People who are new to vim-style-editors and go to neovim are mainly people who would have gone to vim if neovim didn't exist.
It seems reasonable to assume that a lot of new people would not pick up either Vim or Neovim without LSP integration and Tree-sitter.
Vim has adopted a lot of the early features of Neovim and now Vim9 also has things like virtual text for rendering LSP diagnostics in the buffer[1] and there is a Vim9 LSP plugin too. But it does not at all seem likely that Vim would have these were it not for the push from Neovim.
Besides, it looks like Vim still does not have mature support for Tree-sitter.[2]
> Well, the prevalent wisdom of 30+ years of FOSS has been that they're mostly bad.
There are many famous forks from the past 30 years that hardly anybody calls bad. Some examples: Net/Free/OpenBSD, GNU/XEmacs, Open/LibreSSL. These projects allowed people with different goals or values to carry on in their own directions, while also motivating each other to pick up development pace. They have often also shared code with each other.
[1] Which looks like this: https://sr.ht/%7Ewhynothugo/lsp_lines.nvim/
[2] One experimental plugin I came across: https://github.com/mattn/vim-treesitter
Neovim migrated to a more modern style of C and more tightly integrated Lua as its scripting language (instead of conscript). Those are two large potential stumbling blocks for contributors.
From loosely following development over the years, I see names like chrisbra and justinmk who contribute to both projects, but there seem to be many who contribute to neovim but never contributed to vim.
Neovim also seems to have influenced the development of vim: channels, jobs, terminal mode, and issues/PRs on github (instead of mailinglists) felt like shifts in response to neovim.
I think it's also to Bram, justinmk, and other maintainers credit that the two projects contribute back and forth: many vim fixes are merged to neovim and I see big changes get brought back to vim too.
Last time I used vim there was still a thriving ecosystem of vanilla-compatible vimscript plugins. And this thread is full of neovim users who continue to use vim for some use cases, like on remote machines. How many vim users do you suppose use neovim for certain tasks? :)
> Well, the prevalent wisdom of 30+ years of FOSS has been that they're mostly bad.
My experience has given me the exact opposite impression. Forking may not always mutually benefit both projects, but the end result at worst occupies the time of a few disgruntled maintainers who would have likely stopped contributing anyway, and at best delivers real value for users by being responsive to their needs and desires.
It contains the misconception that without the fork and the ability to create what they want to create that the additional developers who themselves aren't getting paid would magically be reverted to additional free workers for a project they don't run even though they can't do what they want. In reality it is likely to lead to more total developers working on the ecosystem.
It contains the misconception that code created for the fork is worthless for the primary project despite the fact that compatibly licensed code can either directly be used or can be used as a conceptual v1 that can be improved with the benefit of the prior work.
> Well, the prevalent wisdom of 30+ years of FOSS has been that they're mostly bad.
If this were well supported people would probably mention actual projects that had been hurt by forks instead of speaking of hypothetical matters for multiple decades. This is brought to you by the same line of thinking that we all ought to work on one foo where foo is a an application because then and only then would open source compete with the billions of dollars poured into photoshop and the entrenched benefit of OEMs supporting the windows ecosystem with its application ecosystem, broad hardware support, billions of dollars to pay developers, and ability to earn money on shovelware and convince grandma to instead download Linux ISOs.
Just because its commonly expressed doesn't mean there is merit to the argument.
And yet, projects that fail to get adoption and foster a community rarely go that far, except if they're small hobby projects that can fit on one or two developers scope.
>It contains the misconception that without the fork and the ability to create what they want to create that the additional developers who themselves aren't getting paid would magically be reverted to additional free workers for a project they don't run even though they can't do what they want.
Projects are not just about core developers. They're also about adoption, documentation (webpages, posts, books, articles), plugins, even themes, and configuration bundles. All of those are split in a fork.
And it's not like without NeoVim most of those vi-style-liking people would have gone to a totally different alternative editor. Most of them would have stayed with Vim. Especially when the differences where small to begin with (but enough to fragment compatibility in many areas).
Devs and users (including new devs and users) that would have gravitated towards Vim, now have the addec choice to gravitate towards NeoVim. The amount of people, that, absense of NeoVim, would have gravitated towards something completely different is, I'd say, much smaller.
>If this were well supported people would probably mention actual projects that had been hurt by forks instead of speaking of hypothetical matters for multiple decades
People have mentioned actual projects that have been hurt by forks. XFree86 vs X.org, OpenOffice.org vs LibreOffice, MariaDB vs MySQL, and others. The xBSD fragmentation didn't help either to them losing ground to Linux.
Such splits aren't always handled well and value is lost when good ideas aren't merged back because of personal reasons and when contributors stop contributing because they are turned off by the drama. See libav vs ffmpeg.
I can see the fork maintainers going into a power struggle if the future is unclear. Maybe some will even write fluffy pieces on how much they loved Bram to gather support...
This admirable. Over time I've become a maintainer of one or two somewhat important open source codebases. One of the codebase owners that invited me to maintain their codebase, a very kind Swedish fellow, didn't know what kind of maintainer I might turn out to be, so when he invited me over beers he explained that a maintainer should be gentle with contributors the way a parent should be gentle with a young child when the child shows them a drawing they made. That image stuck with me. I don't know if I would have been a rude maintainer w/o that talk, but I often think of it, and I try to live up to that every time.
More crucially has anybody ever made a faster render? I mean it´s 2023 and I'm still seeing gvim in Ubuntu redraw my tabs from top to bottom in maybe 0.1 sec but it's definitely noticeable.
Bram was a hero for his long term dedication to such a great piece of software, and for the great design he put into it that made so many people’s lives better.
Justin and the other Neovim developers are heroes for making a great piece of software even greater. Despite all the drama that people like to confect, the Neovim devs always show the proper respect to Vim and Bram.
It is one shoulders of these giants we ALL stand on.
I know the project will likely continue, but I can't help but thinking: what now?
It brings up this issue of death in software for me. Software is getting old enough now that it is starting to outlive its authors. RIP Anthony Grimes and Ian Murdock. I have used both of these men's software after their demise[1][2], and I am grateful for it.
However, it does make me think. Grimes' software continues to have issues filed against it[3] by folks unaware that no one is getting notifications for them. On the other hand, Debian was popular enough to continue after Ian's passing, and continues to gain momentum.
I know it might be too soon for me to wonder about these questions to an audience. These were the giants on whose shoulders we continue to work today. I'm glad their code persists.
1: https://github.com/Raynes/fs
Bram Moolenaar has died - https://news.ycombinator.com/item?id=37011324 (4272 points, 430 comments)
I feel that this would be an ideal thing for one of the various open source foundations to address. I.e., provide a single-source hosting environment for open source projects without needing to lean on for-profit corporations, which would include some form of hit-by-a-bus solution for those projects that lose a core (or sole) developer.
Trying to piece this stuff together after the fact is always a chore. And no amount of "well, they should have a plan in place" will help. People don't think they're going to die tomorrow, so there's always a reason to put it off for later, so they do.
I don't think anybody's worried about Linux going poof if Linus unexpectantly returns to his home planet, but there are plenty of projects that might have some issues. Having all of the domains, DNS, hosting, etc. somewhere with a real employee that can be contacted to move control to new people if required is a good thing.
I don't believe these are parallel, as IIRC, Ian was not directly involved in Debian since the late 90's, at least not in a day-to-day manner in the way Bram was, or say the way Linus is still managing Linux to this day.