Vim Boss(neovim.io)
neovim.io
Vim Boss
https://neovim.io/news/2023/08
122 comments
It was 25 years ago this fall that I got a job in the IT department of my university and my boss gave me the perl and vi O'Reilly books so I could start programming on the unix servers. Like you, I've used it (and vim) every day of my career since then.
I have to agree here, I’ve worked on some tremendously complex control systems and the documentation has been so good that anytime I’ve needed info it was easy to find.
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.
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.
Vim has soul. It is that chisel you inherited from your grandpa that you keep using. It fits well in your grip and is comfortable, even though it lacks the soft rubber that the new ones in the store have. It's a tool with its own history.
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.
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.
A slight difference though. If a newbie picks up grandpa's chisel, it doesn't get glued onto their hand until they google the three magic words they must shout to make the chisel come off.
I understand your metaphor but I think it's probably a stretch.
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.
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.
It's not a stretch that practically everybody who accidentally ends up in vim (often because it's git's default editor) ends up googling how to exit the program. It's the tool that you can't even drop by any intuitive action.
This is true of the original vi but not of modern vim, where both the landing page and the message shown on ctrl+c clearly state how to exit. ctrl+c will also exit insert mode, so you don't need to know about modes or the escape key.
Of course it is possible that one might not think of using ctrl+c, but that's lacking general shell knowledge, not vim knowledge.
Of course it is possible that one might not think of using ctrl+c, but that's lacking general shell knowledge, not vim knowledge.
Its a terminal program, most people don't know how to deal with those when starting out.
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.
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.
It's like the phial of Galadriel: a light for you in dark places when all other lights go out
That’s a great way to put it. Who are you?
I reflected on my Vim journey after Bram passed away. It has been my only constant professional companion in the past 10 years - from university projects to FAANGs to everything-on-fire startups. All professional work I have done - the ones I am proud of, the ones that I am ashamed of, the ones that got me promotions and the ones that resulted in $M SEVs - was done on Vim. Oses/DBs/PLs/companies/co-workers come and go, but Vim has been forever.
Thanks Bram.
Thanks Bram.
From a linked article [0] there's a screenshot of Bram's github activity and this text:
> 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.
https://github.com/brammool
[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 †.
https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
> 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.
https://github.com/brammool
[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 †.
https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
Today at a train station in the Netherlands (Utrecht) I noticed something special. I saw the letters hjkl on the sign in reverse order. These letters indentify the platform areas where you can enter the train. Depending on the length of the platform and the area where the train has entrances, it shows the letters.
https://postimg.cc/mcCWhMXw
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.
https://postimg.cc/mcCWhMXw
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.
Although, thinking about it now, the letters do come after each other in the alpbabeth except that the I is missing between the H and J, but maybe they did that intentionally because it can be confused with the lower case L. So maybe just coincidence after all, but still it was special for me. I never saw this at the trains and now suddenly the week after Bram passed away this shows up.
not a coincedence or tribute - same has been the same in the uk for many years. the letter "i" is typically not used for such purposes because it can so easily be confused with numeric "1" or alpha "l".
Pretty sure it's a tribute -- local trains in NL do not have named carriages FAFAIK, because there's no reserved seating. Only international trains have those indicators, and they do not go to Den Helder.
Definitely not a tribute. These are not carriage names, but stopping location indicators to show where the train will stop on the platform. Train station platforms have named areas.
Video in Dutch: https://www.youtube.com/watch?v=JPvh9SaQbUY
Video in Dutch: https://www.youtube.com/watch?v=JPvh9SaQbUY
Although I use vim, I associate these letters more with the home row for touch typists.
Home row is jkl;
As a reminder, that's why most keyboards have physical indentations in f and j.
They're meant to be felt by index fingers.
They're meant to be felt by index fingers.
Fun historical note: Mac keyboards until the late 90s or so had the bumps on the D and K for the middle finger. In a vacuum either's a reasonable choice but going back and forth was always fun.
I got my first split keyboard, and I kept getting lost. So I took a knife, and cut an indentation on the keys under my index fingers. Works great.
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.
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.
The home row is the whole row of keys. jkl; are the home keys of the home row that your fingers rest on.
These signs are location indicators to show where the train will stop at the platform!
Video in Dutch: https://www.youtube.com/watch?v=JPvh9SaQbUY
Video in Dutch: https://www.youtube.com/watch?v=JPvh9SaQbUY
I once interviewed an intern candidate who bragged about getting into an argument with Bram on the mailing lists over a possible vulnerability. Bram insisted it was not important, and this young gun insisted it was.
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.
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.
Was this kid arguing about the automatic encrypt/decrypt file capability and Bram's unwillingness to use a cryptographically secure algorithm? It was a long, long thread that got heated.
I was with Bram though! It was never meant to be secure in a cryptographic sense...
I was with Bram though! It was never meant to be secure in a cryptographic sense...
"Never meant to be cryptographically secure" should never go together with "encrypt/decrypt file capability".
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.
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.
I am not sure it's so black and white with encryption. It depends on your threat model. Keeping it secure from an angry ex-girlfriend is one thing, but keeping it secure from a three letter agency is another.
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.
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.
>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.
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.
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.
the three letter agencys built modern encryption with explicit loopholes. [0] They probably made bitcoin too.
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-...
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-...
This would make sense if only it wasn't faster to run AES_GCM or some other AEAD, than whatever they did there.
That sounds really familiar tbh. Basically the argument was "this is insecure" vs "Yeah, its supposed to be like that".
at least they cared enough to stick to their guns i guess
Indeed, not 100% clear but it felt like GP was criticizing the kid.
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.
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.
Bram listened to and engaged in most conversations, I think. He was very approachable.
The young guy was fairly skilled at technical stuff, but his story about arguing with Bram was an insight into his interpersonal skills. It wasn't what lost him the spot though. I personally liked him but he didn't really perform on the nuts and bolts challenges we present to candidates.
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.
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.
The article talks about modesty and meeting in the middle, but I get the impression that the younger dev didn’t want to budge or understand the other point being made by Bram.
I haven't followed that but that is having an opinion. Sometimes you can only agree on disagreeing.
https://en.wikipedia.org/wiki/Benevolent_dictator_for_life has a list of BDFLs. Bram is the first BDFL in that list who has passed away. We're in for a generational shift the coming decade(s). It makes sense to prepare - that is how you preserve a legacy, and the community.
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.
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.
So the result of me writing this was that John Gruber was added as the BDFL of Markdown. Creator, sure, BDFL, that's a stretch.
Thought a linked article:
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!
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!
I don't know if it's necessary to be competitive about eulogies, but the one you posted was also touching. Thank you for posting it. The picture of Bram's GitHub contribution graph is haunting.
> Disclaimer: I'm not even user of either of (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?
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...
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...
I've been a happy vimmer for 15 years. I've been dabbling in helix for a month and liking it a lot. The ast-aware selection capabilities--while not habit yet--feel like a fledgling superpower.
Neovim has a plugin for that too.[1] Is Helix different in how you can navigate the syntax tree?
[1] https://github.com/nvim-treesitter/nvim-treesitter-textobjec...
[1] https://github.com/nvim-treesitter/nvim-treesitter-textobjec...
Seems similar. I haven't used the text objects stuff enough to be sure--I'm just excited to do so.
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.)
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.)
> As soon as I read "programmable", I'm off. I just prefer fixed-function editor that suits my taste
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.
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.
> 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.
Exactly, just because you can doesn't mean you need to, or should.
My .vimrc:
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.
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.
While we're at sharing neat vim configs, here's the one I was quite happy with at the time: I got tired of indent style arguments. I don't care. So I wrote a little heuristic to detect indent style, then configured vim with my preferences, and added this to .vimrc:
> 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.
> 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.
>Vim is what I mainly use out of habbit. It only requires typing vim as opposed to nvim.
I got used to typing vi instead. It's shorter
I got used to typing vi instead. It's shorter
alias vi=vim
alias vi=nvimOn a Debian(-based) system, you can play with update-alternatives
https://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 ;)
https://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 ;)
It also works on fresh linux installs without the "damn I forgot to install vim" moment.
My .exrc file is < 10 lines and that + ctags is enough for me to use vim for daily development across multiple languages.
>"7 Habits for Effective Text Editing 2.0"
>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]:
https://news.ycombinator.com/item?id=37013315
>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]:
https://news.ycombinator.com/item?id=37013315
Vim has had a legitimate impact on my life. Over the past 15 years I've been using it, "set -o vi" and similar in psql/ipython get added into my rc files almost immediately on a new host. Many, many hours upon hours of living in a shell have been made so much more enjoyable because of his work.
Thank you for posting this. Rest in peace, friend.
Thank you for posting this. Rest in peace, friend.
Same here. Learning Vim commands has had one of the greatest ROI of anything I know. It's been invaluable over the years, and has probably saved me hundreds of hours of interacting with a computer. It's become muscle memory a long time ago, and editing text and moving a cursor on the screen takes no effort at all.
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.
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.
In a world of fleeting software, Vim is a timeless masterpiece.
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.
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.
I think this is one of the main important things about vim. The longer it exists , the longer it will. It has outlived so many modern text editors. I hope that it lives on as long as I live and longer.
So often we hear after someone dies how great they really where when infact they were like most people, a mixed bag. We all have ups and downs etc.
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.
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.
I occasionally ponder on how frustrating it is that the deceased don't get to hear their eulogies. It would have been amazing for Bram to have been able to experience all the outpouring of support and love from people he is interacted with during his life. Especially in a context where the speakers aren't considering him as an audience -- they're sharing their deep and true feelings.
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.
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.
This is why I always make it a point to tell people how much I appreciate them and why (when I do, I mean). It can be awkward at first, but I’ve developed a good self-deprecation that lets me excuse myself for being gushy (“I might start crying; I’m a crier!”), and that disarms people for the most part. I think it’s really important that we let people know how much we value them and why we honor/respect them when we do. Because most of us do wander through life in a cloud of unknowing and uncertainty.
Off topic but your comment makes me think of Nick Drake. He died at 26, before even knowing he'd achieved anything, his music barely listened to, probably feeling a failure. Posthumously he's one of the world's most acclaimed recording artists.
RIP Bram.
Good example, although Van Gogh is probably the more cited.
“The Doctor and Amy take Vincent Van Gogh - who struggled to sell a single painting in his own lifetime - to a Paris art Gallery in the year 2010”
https://youtu.be/ubTJI_UphPk
https://youtu.be/ubTJI_UphPk
I remember the emotional impact of that scene hit me hard when I first saw it. It still hits 89% as hard now upon many repeat viewings.
Another example is Stieg Larsson, author of the Girl with the dragon tattoo triology. He died before these books were published.
Also John Kennedy Toole, his novel The Confederacy of Dunces was published by his mother after his suicide and it ended up winning the Pulitzer.
At least in one of the Van Gogh movies, he says something like 'one day, people will understand'. To me, that suggests that he knew the value of his work whereas OP suggests that Nick Drake didn't know that he created something that people will value.
An example from South Africa: https://en.wikipedia.org/wiki/Searching_for_Sugar_Man
Larry David had the same thought, and it was the theme of the episode "The Covid Hoarder" in Curb Your Enthusiasm wherein Albert Brooks stages a funeral for his non-deceased self.
Cue "Waking Ned Divine" reference: https://www.youtube.com/watch?v=UXe_kRQdHfU
That's what birthdays are for. I like to think, anyway.
Aside from the POSIX toolchain/kernel/etc and browser (which I'd use if it neatly embedded into vim), vim and its siblings are together the most used program on my machine.
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!
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!
Bram is a guy who could have chosen to make millions but instead helped millions.
Thank you Bram for everything. Your talk, 7 Habits For Effective Text Editing 2.0 inspired me and it started my Vim journey. Using Vim all these years has been a complete joy. You will not be forgotten.
Link to the talk: https://www.youtube.com/watch?v=p6K4iIMlouI
Link to the talk: https://www.youtube.com/watch?v=p6K4iIMlouI
It is nice to see tasteful and profitable disagreement in place of simple drama. It's a credit to all parties.
sorry, what disagreement? I didn't find any in the article.
The implied disagreement for why neovim exists to provide functionality that wouldn’t have been merged into vim.
Disagreement insofar as the direction of vim. Neovim choosing to go there on way on functionality they wanted to implement both ultimately enriched vim as some ideas found there way into vim proper and gave the community additional options.
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.
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.
Some people take issue with NeoVim, because they believe it splits the Vim community and takes people power away from Vim development.
> because they believe it splits the Vim community and takes people power away from Vim development
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.
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.
>I don't understand this point, and I tried to parse it and still don't. (...) 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
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.
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.
> 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.
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.
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.
>You're not dividing the same-sized pie.
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.
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.
I'm not so sure.
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.
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.
You are stating these things as though they were established facts. But they seem to be opinions. Or do you have data to back them up?
> 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
> 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
This thought process contains the misconception that non-paying users are the primary currency that sustains a project as opposed to developers even though the former are nearly worthless and the latter vital.
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.
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.
>This thought process contains the misconception that non-paying users are the primary currency that sustains a project as opposed to developers even though the former are nearly worthless and the latter vital.
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.
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.
> 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.
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.
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.
I guess you're right, the logic you describe is simple, but I submit that there's a more fundamental logic: If the folks who split away pull people out of the original community, it means there was demand for the things that prompted the split in the first place.
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.
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.
What splits it more, IMO, is that neovim went in a non-compatible direction with many of their design choices. They have good arguments for doing so, but it still means that writing community plugins that can work with either version of vim is inherently harder.
I guess if they haven't gotten in a non-compatible direction, then they wouldn't have made enough change to guarantee a fork.
That feels a bit like criticizing all the c-style programming languages for splitting the C community... Which is an analogy I rather like, as it suggest Vim has become so foundational that its legacy goes beyond the direct users of it. I've certainly found that to be so, as in addition to using vim itself, I also use its key bindings wherever I can.
Some people can't grasp how the world is working.
Is there any disagreement on who is going to support Vim moving forward?
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...
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...
Neovim and vim are very independent projects, so this doesn't really affect neovim all that much. Is that what you're talking about?
Not entirely correct since neovim never stopped merging upstream patches from vim.
So what happens in vim does influence neovim.
I thought this was quite well written. "Be pragmatic, not dogmatic" is a very sensible rule of thumb.
> Even when treated rudely, Bram usually responded only to advance his understanding of a problem to solve.
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.
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.
Is there anything like MacVim on linux these days? I mean gVIM is pretty usable with tabs but I'm wondering if anybody cared enough to make something a little fancier GUI wise? Just good looking slick window decorations, better integrated with eg. GNOME in Ubuntu.
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.
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.
I really appreciated this post.
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.
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.
I sucked at Vim. My tribute to Bram will be to learn it and master it.
It is one shoulders of these giants we ALL stand on.
It is one shoulders of these giants we ALL stand on.
thanks Bram.
Thanks Bram, RIP .
I'm shocked. I've been a vim user my whole life. I use neovim lately, but I didn't even know Bram was dead. I've never interacted with him personally, but I've interacted with the tool he wrote and the documentation he wrote almost on a daily basis. Vim is part of me.
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
2: https://en.wikipedia.org/wiki/Ian_Murdock
3: https://github.com/Raynes/fs/pulls
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
2: https://en.wikipedia.org/wiki/Ian_Murdock
3: https://github.com/Raynes/fs/pulls
There is another thread on HN about vim development going forward, posted on the Google Group for vim development. Christian Brabandt mentions several issues that will need to be resolved, e.g. the hosting situation for the site.
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 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.
https://sourcehut.org/ fits this pretty well
SourceHut is great but they still do not support[1] organization accounts. Team development, especially for relatively big projects like Vim is a pain in such environment. It's also sad they stopped publishing regular "What's cooking on SourceHut" blog posts.
[1] https://todo.sr.ht/~sircmpwn/meta.sr.ht/29
[1] https://todo.sr.ht/~sircmpwn/meta.sr.ht/29
What? Project founders and software authors might not always be around?
Bram Moolenaar's passing became public last Saturday:
Bram Moolenaar has died - https://news.ycombinator.com/item?id=37011324 (4272 points, 430 comments)
Bram Moolenaar has died - https://news.ycombinator.com/item?id=37011324 (4272 points, 430 comments)
>On the other hand, Debian was popular enough to continue after Ian's passing, and continues to gain momentum.
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.
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.
keep going bro good post
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.