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.
TS can be slow in some situations.
https://github.com/tree-sitter/tree-sitter-julia/raw/refs/he...
open this file with and without treesitter . And neovim will slow to a crawl with TS on. But the traditional regex highlighter can handle it fine. (a file such as the link posted above typically is never meant ot be opened since its machine generated , this is just to show you TS can be slow on large files)
TS is faster in other situations.
for example with TS highlighting enabled entering "(" in the buffer is definitly faster in a julia file. (you can test this by holding down "(" in a .jl file and see the difference between TS enabled and only regex highlighting).
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
>>When catastrophic fires occur, experts often blame the so-called wildland-urban interface, the vulnerable region on the perimeter of cities and suburbs where an abundance of vegetation in rugged terrain is susceptible to burning.
>>Yet the fire disasters that we’re seeing today are less wildland fires than urban fires, Cohen said. Shifting this understanding could lead to more effective prevention strategies.
>>“The assumption is continually made that it’s the big flames” that cause widespread community destruction, he said, “and yet the wildfire actually only initiates community ignitions largely with lofted burning embers.”
>>Experts attribute widespread devastation to wind-driven embers igniting spot fires two to three miles ahead of the established fire. Maps of the Eaton fire show seemingly random ignitions across Altadena.
>>“When you study the destruction in Pacific Palisades and Altadena, note what didn’t burn — unconsumed tree canopies adjacent to totally destroyed homes,” he said. “The sequence of destruction is commonly assumed to occur in some kind of organized spreading flame front — a tsunami of super-heated gases — but it doesn’t happen that way.
>>“In high-density development, scattered burning homes spread to their neighbors and so on. Ignitions downwind and across streets are typically from showers of burning embers from burning structures.”
>>This fundamental misunderstanding has likewise led to a misunderstanding of prevention. No longer is it a matter of preventing wildfires but instead preventing points of ignition within communities by employing “home-hardening” strategies — proper landscaping, fire-resistant siding — and enjoining neighbors in collective efforts such as brush clearing.
>>“If we think it’s wildfire, then we tend to maintain wildfire as the principal problem — with wildfire control as the solution,” Cohen said. “However, there is no evidence to suggest wildfire control is a reliable approach during the extreme wildfire conditions when community disasters occur.”
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?
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.
I got nvi for Linux build and working using the patched source code from Debian for nvi version 1.81.6-17-debian. It is 39768 bytes on my amd64 machine (I don't remember if I used some extra flags to make it smaller).
I replaced vim for the vi binary with nvi in my Linux From Scratch fork, thought vim is still left. Yes, my vim is similar in size to yours, good idea for an upgr... - down shift!
You are correct, I ignored the "static" point. My nvi size was dynamically
linked. I want to learn static builds, even thought my distro of choice LFS is
not very forthcoming in this respect.
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.
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.
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.
I’ve gone from vim to vsc, and now to sublime. Sublime has a nice plugin ecosystem and is in python as well, and most importantly has LSP support written by the authors. It also is wayyyyy faster than VSC now; basically as fast as VIM, but has a better UI and I have vim keyboard integration.
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.
> 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).
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.
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!