As a long time (20+ years) vim user the passing of Bram came as a shock. But it has become clear to me that the project is in safe hands, and I've seen slow but steady progress, continuing the tradition of stability that Bram always safeguarded for 3 decades.
I do try out neovim from time to time, but I don't care for Lua (vimscript is easier to read and less verbose for .vimrc), I don't need an LSP and I found treesitter often buggy and slow.
So I'm sticking with vim, here's to another few decades more, thank you to all maintainers!
You can pretty much ignore Lua and still use neovim, but I see your point. Lua is a big part of the appeal of neovim to me, and I'd probably have stuck to Vim without it. (Another big part is its embeddability - I can have a real neovim instance processing my commands from VS Code when I need to use that).
I agree with you about treesitter too: it's not really better than the old regex way in terms of (non-)bugginess in my experience, and I've been hearing more and more reports of it being much slower than it's claimed to be.
Strange, this is the first time hearing Treesitter is slow. From experience, Treesitter has been incredibly fast for me (when running its core functions). I’m not discrediting your observation, but it might be something else in the pipeline.
LSP=? Web search comes up with language server protocol (among many other things, this seemed the most fitting), do you mean language server?
Yep, LSP is Language Server Protocol, and NeoVim has (I believe) built-in support for it - as in, it can talk to a language server using LSP and use that for, for eg., "Go to definition" type shortcuts that are language-aware and more robust than pure syntax-based attempts.
I'm happy with this "maintenance mode" tag. Personally speaking, so long as it continues to get security fixes and the build system is kept working, I'm a happy user.
I think so too. Any new features can be implemented as a plugin and one they're proven useful/stable enough, they can get refactored in the main project a la emacs.
Vim in maintainance mode makes a lot of sense to me. For larger features and refactors it makes more sense to turn to neovim, which has already undergone a lot of modernization work, at times breaking with old vim.
I started with vi, a long time ago. I do not remember when I switched, but it was most likely when I start using Linux. I will stay with it until I die at this point. http://crn.hopto.org/unix/#vim
i don't understand the issues with the github account. they tried to supersede the ownership of the organization by declaring the owner dead which would have deactivated the account. but if the family has full access to the account, couldn't they just assign a new owner to the organization?
Yes, that's what they did. I assume that they didn't want to burden the family with yet more formalities.
Big fan of Vim. One thing I wish they fixed is the UX around opening a file twice.
Fwiw it's useful in split mode to view and edit simultaneously different parts of the same text.
Not only in split mode, as you can also just switch between two buffers (or more) focused on different parts of the text.
What specifically do you need fixed?
Well, if I open the same file that I already opened in another terminal, then it shows me the PID of the Vim process and a question about removing the lock file.
What I normally do is kill the PID, and then open the file again and tell Vim to remove the lock file.
This can be automated. But even better would be to allow me to take over the session in case there were any unsaved changes.
There's the built-in `packadd editexisting` to take care of that; On Unix https://github.com/gioele/vim-autoswap could be more convenient.
On Linux, I can compile a static vim 4.6 (1997 mar 13) with size of 514K
If I compile static vim 9.1 (2024 jan 02) I get size of 3.7M
When I compile a static nvi, I get a size of 575K. And the resulting binary segfaults
On NetBSD I use nvi but for Linux I am using vim 4.6
Small and fast
omg, I’ve used vim everyday for more than 15 years and did not know Bram died. RIP
Discussed at the time on HN, August 2023:
<https://news.ycombinator.com/item?id=37011324>
And yeah, that one hit really hard.
Seventh most upvoted HN post of all time, under Steven Hawking's and Steve Job's death. https://hn.algolia.com/
Now that is remarkable- but so is vim.
Bram's passing and the split into basically two code bases (Vim, Neovim) and three customization languages pushed me over to Emacs. I switched back and forth for years, as many others do, but I didn't want to deal with having to use one or the other depending on scripting language.
[edit: grammar]
>Bram's passing and the split into basically two code bases (Vim, Neovim) and three customization languages pushed me over to Emacs.
The resulting increase in height, strength, intelligence, and sexual appeal is no doubt a nice bonus.
Ah, someone has arrived with matches and kindling for the classic Emacs/Vi flame war.
But I'm pouring water on it right away. I'm glad you found peace with Emacs.
Yes to all perusers about to make some holy war comment or crack a long-dead joke about editors, please don't. Most of us out there are happy you've found peace or joy with your editor of choice.
Keep the holy war dead and let people decide for themselves what their editor should be. I use Emacs but I have many colleagues who use Neovim and we all are very supportive of each other.
I certainly did not intend to ignite any flamewar. IMO both Emacs and (Neo)Vi(m) are fine editors. I wish more people would accept other people's right to have a personal preference.
My choice of Emacs was based on what I see as a fragmenting of (Neo)Vi(m) ecosystem. When writing extensions, I was uncomfortable with a "which of the three languages do I use" decision. The only common language is old Vimscript, and both forks are moving on from it and neither seems willing to support the other fork's preferred language.
That's their right, to be sure. It's just a deal breaker for me.
Curious to know whether you considered Visual Studio?
I used vim happily for 15 years. When deciding to move on to something else, VSCode won over emacs.
I'm not the person you asked but I chose Emacs over VSC because it's just a better fit for a lot of things for me. I do think the telemetry Microsoft harvests through VSC is an issue to consider. While it is "just" metadata and no file content, they're getting your entire project structure down to file extensions. I don't see why I would want Microsoft to know what I'm working on. Anyway, the key point for me was ORG mode and that plugins for Go and C++ suck(ed?) in VSC. There are other things, the intellisense is slow, the vim plugin is terrible, the constant Microsoft product pushes are annoying, there is no Magit and so on.
I think it's important to say that I don't dislike VSC as such at this point. Because I probably made it sound like I think it's terrible. I don't I think it's ok. I didn't mind using it for Typescript as an example. Over all I think it's average at best. I get why people use it, it's easy to setup. It's easy to share configurations and so on. I probably would have gone from vim to neovim if it wasn't for doom emacs though.
I think the major advantage both emacs and vim have though is that they're always good. A lot of VSC users are now switching to Zed and that hamsterwheel will go on and on. With vim or emacs you'll never really have to change anything.
Pretty much the reasons I don't care about VSC. Sensible telemetry is not an issue for me, but pushing electron while there are much more performant solutions is one. I'm much more amenable to the Emacs and Vim's plugin/package solutions than VSC. And they're extraordinary stable.
I’m also unease about the open-source-but-not-really VSCode situation. I don’t know how useful an editor you can build from the available source, which is enough for me to not consider it seriously. I’ve been bitten before.
Without telemetry: https://vscodium.com/
Is it?
https://github.com/VSCodium/vscodium/blob/master/docs/index....
> Even though we do not pass the telemetry build flags (and go out of our way to cripple the baked-in telemetry), Microsoft will still track usage by default.
Vim (used to be?) insanely much faster on large files, it’s already installed everywhere, it has built-in highlights for all languages under the sun, configuration is easier to sync around (in my opinion).
That said, I use both, and jetbrains.
Why did it have to win?
Emacs is fundamentally different, vscode is only convenient if there is no intention to change things.
Tangent: Despite the misleadingly similar naming, Visual Studio and VSCode are two completely different MS products. I too use VSCode for most of my programming these days, but since I don't currently program for Win32 or UWP or .NET, I haven't seen a reason to install Visual Studio even though I have a Windows machine and they have a zero-cost Community Edition.
I'm familiar with Visual Studio (in my professional persona) and Code. Too many dials and knobs and displays. Telemetry is not a huge issue for me, but I understand why it bothers some people.
I had been jumping back and forth between Vim and Emacs for several years in my hobbyist persona for years. When in hobbyist mode, I prefer to avoid anything that reminds me of my professional mode.
VS and Code are noisy and intrusive. Emacs and Vim (and Neovim) are not.
Can’t run vscode in that black box thingy.