The State of Vim | Hacker News Reader

The State of Vim

lwn.net

264 pointssigna11200 comments

VIM seemed to have fared well under the new leadership, despite not being able to control the timing of this power transfer. Maybe other BDFL projects would be inspired by VIM's experience and setup successors early.

https://en.wikipedia.org/wiki/Benevolent_dictator_for_life

that'd be the wrong lesson to extend a period of using a bad governance model for longer

You need someone to say 'no' to all the stupid ideas, and also to the occasional good idea to stay focused. Committees and communities are quite bad at that. IME the BDFL model has mostly worked best for open source software development, unless the BDFL is a complete ass of course.

(also software projects don't need to be democracies, e.g. people won't starve or sent to the gulag if things go sideways)

It's the best, when you find one. But the approach is also the riskiest. You may not even pick a BDFL to begin with (I'm sure many of us can name certain repos overly held back by a bad or muddy vision, or being overly conservative with feature/pull requests) . or that B fades away for any number of factors. Committees sacrifice that cohesive vision and agility for being able to have some checks to potential rouge actors.

This is what another commenter wrote:

> Braam really took Neovim personally and got better at getting stuff into vim that he wouldn't merge before once neovim was arround as a competitor. I really lost track of vim in the last years because neovim is just a solid platform with an active community.

I think that's the answer - the specific makeup of any given team isn't as relevant as competition which spurs competitors to either keep up or the more successful upstarts to take over.

> or being overly conservative with feature/pull requests

We saw some complaints about a repo like this I forget for what project some weeks back here on HN and it came down to, people dropping a PR and then the maintainer left holding the bag if something goes wrong, having to maintain someone else's code, which can become a problem if its a completely new feature they didn't implement or want, but users wanted. The other case is, they fix a bug, then disappear, so if the maintainer has feedback, now they have to take time to check out the person's code, update it, out of their current planned work.

I wonder if more open source projects would benefit from adding plugin architecture so people can do those one-off features as plugins without "tainting" the core project.

> But the approach is also the riskiest

Honestly in open source I'd argue it's not. If an OSS project has significant usage, if BDFL struggles/etc - community forks can put the project back on pace. NeoVim is the classic (successful) example that gave us a great alternative while also nudging the BDFL into the modern age.

> potential rouge actors

Communist assets?

Not necessarily. Sometimes people infiltrate projects with the intent of sabotaging them. This may be done by causing a controversy, or else making bad technical decisions on purpose.

I think you missed the joke. "Rouge" is French for red. Most likely it was meant to say "rogue" but it was misspelled.

One of the most powerful ideas I've come across is Arrow's impossibility theorem, which basically states that you don't get a lot of nice group choice outcomes without a dictator in the mix. It's a math formulation, so its not commenting on the realities of a despot, but rather, someone's choices will always dominate if you want a certain set of properties in the decision making.

https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theore...

Or HN too. I think most of us would agree that dang is a very good moderator.

> software projects don't need to be democracies

Especially opens source ones, where anyone can spawn their own kingdom via a simple "git clone".

> unless the BDFL is a complete ass of course.

I think in the case of Linus, you REALLY have to be strict. I mean, its arguably one of if not the most used pieces of software deployed in enterprise and globally for all manner of use cases.

Yeah, “dictator” was probably the wrong word. The characteristic of an actual dictator (even a benevolent one) is that they can enforce their will through violence if needed (benevolent ones usually don’t, but they could).

As quote goes, “I thought we were an autonomous collective.” Humans have some sort of tribal or pack instinct; if we want to do a project, we’ll often naturally form up around the person who’s doing it, willingly and without compulsion. The leader is the leader because everyone agrees they are doing good enough.

Open source project is sort of an ideal form of this. Unlike physical projects, the ability to fork for free means that the leader doesn’t even have the implicit moat that a potential alternative leader needs to take the current work-in-progress away from them.

BDFL is just a joke title.

Unless your software deals with tracking people within an organization that will of course comply with the political parties that rule the regions where there software operate.

If Vim tracks you then that’s a willfull act that breaches trust.

IMO no governance model can defend against supply chain attacks.

IMO you shouldn’t try to fix things with governance model which it doesn’t fix. Use a governance model that leads to good governance. In technical and creative work single highest point of authority is best.

Not because they have perfect knowledge or are the best but because dictator led models lead to best alignment - which is something you simply need to execute when performing a complex task with many stakeholders.

Dictator led models aren’t best for everything. But for complex tasks with specific fixed scope with multiple concurrent contributors it seems to be the only model that works (if there are case studies as counter example I would love read on them! I.e. complex task, more than 10 contributors, non-dictator governance).

Hmh, I don't have a case study at hand, but there are many reports (and management self-help literature) where teams are shown to be the superior approach to complex situations, especially in software development. Furthermore, considering that there are only about 50 identified open source projects out there with a BDFL [1] and only a few of them are clearly best-of-breed, while there are many best-of-breed projects that do not use a BDFL I'd wager that the perceived superiority of BDFL can at least in part be attributed to the perennial hero worshiping we like to do.

[1] https://en.wikipedia.org/wiki/Benevolent_dictator_for_life

Any tiny project on Github, Gitlab, ... which is maintained by one person but accepts PRs and feedback from outside contributors is essentially a BDFL project.

The single project owner decides what goes and doesn't go into the project by merging or rejecting PRs. People are still free to maintain their own forks with contributions that are not accepted into the main version.

In a way, the entire Github workflow is built around the idea of BDFL managed projects.

IMHO - No - having individual contributor workflows is diffenrent thing than aligning 10 people. The question is not who gets to do the decisions but how the team aligns itself and coordinates.

It’s an accurate observation that single contributor projects work well since then there is no need to spend effort in coordination and communication.

> The question is not who gets to do the decisions but how the team aligns itself and coordinates.

...IMHO it's the other way around, somebody needs to do the difficult and unpopular decisions exactly for those hopefully rare situations where the self-coordination within a team fails (and doing that in a way that doesn't piss off people in the team). In the end, contributors to an open source project are also just a very loosely coupled team.

'Unpopular' decisions are much easier to do in projects that have a universally accepted and respected BDFL (ideally the project founder) than in most 'commercial' teams led by random 'management-caste' peeps.

“many reports (and management self-help literature) where teams are shown to be the superior approach”

Isn’t the manager himself the BDFL - or a part of a BDFL led chain of command - for the team he is empowering in this case?

He does not give out the organizational governance-authority just by empowering the team.

Having a BDFL does not imply micromanagement or not empowering teams. It’a a different granularity role than implementing day-to-day issues.

There are people who are really talented leaders. The problem are bad leaders - not the governance model IMO. And this is not a “no true scotsman” argument since effective leadership is a documented and observable phenomenon.

Lack of authority is probably better than poor leadership but not better than good leadership (e.g. legendary John Kelly of Skunkworks fame for an fairly well documented example).

Good point, and I wholly agree that there are really good leaders out there. But I wasn't trying to say that leaders are necessarily bad. I was trying to say that BDFL setups are not necessarily "the best" and there are good reasons to think that other forms of governance have just as good or even better track records. We do not talk about them that much because, I think, we just like hero stories and they are easier to tell with BDFL than with groups.

One big question is why presumably "open source" projects still consider in 2025 to be acceptable to be hosted on Github (especially for those with the most important contributors not being USian).

Saying "no" is the easiest job in the world, and committees are pretty good at it. That's why we have decades-old design failures everywhere, because saying "no" to an improvement is so much easier that doing the actual governing and resource allocation to see it through, especially with volunteers

And given the article describes big fails at basically every aspect of project management (from github account to money and website), not sure where you see the benefits of the supposed "focus"

> committees are pretty good at it.

I don't know it seems to me that committees are famously bad at it, so that we use "design by committee" for something that refuses to take a single direction and either makes bad compromises or says "yes" to all options.

There are two types of comittees:

Those that are paralyzed by fear of change and say no to everything, and those that are afraid of offending people and say yes to everything. Both are counterproductive.

Reality is not binary, so this extreme simplification is counterproductive when describing one

I agree, committees are good at saying no. They tend to say no to two not perfect ideas and then force a consensus containing most often the worst aspects of both original approaches. The good news is that the result is so bloated that can‘t be changed and so provides a stable foundation for years of misery.

There are counter examples of course but the power dynamic of committees is not conductive to results that have properties desirable in software.

When I think about the two models, I have Linux as the dictator type and XML as committee designed. Both are functional enough, but the while so few data points are hardly conclusive, I think it's generally indicative.

I'm not a particular fan of XML, even if it's functional enough to get the job done.

Of course you have to find a dictator that is ready to invest all the time and energy to care for a project over a prolonged time and is actually capable of doing so while avoiding to alienate the user base. That's a pretty tall order.

> I'm not a particular fan of XML, even if it's functional enough to get the job done.

XML by itself is okay-ish. The true design by comittee disasters are the specs surrounding it. XMLSignature, SOAP, etc

> Saying "no" is the easiest job in the world

It depends on your motivation. Probably a lot (many, most?) committees can just sit pretty and try to do as little as possible. But a lot of software projects exist by getting attention, and they tend to do that by adding features. A lot of FOSS maintainers find it super hard to say no. For some anecdata: I have a small/medium project and I've found that just the energy requirements of really thinking about everything everybody proposes are pretty high. I could just say "yes", but then I'm on the hook. I could also just say "no", but then I'm discouraging people and not really giving them any information about how to contribute productively--this would be something like, "sure we could add a flag to turn video upside down, but I'm concerned that putting this kind of functionality in flags means we'll have a UX of 1000 flags that no one can remember or use; should we start considering building another place to put this kind of functionality?

Your anecdata supports the no part:

> just the energy requirements of really thinking about everything everybody proposes are pretty high

Indeed, that's why it most often results in a no (your ending quote is just a polite way of saying no), and you're right about the discouragement part, and that's one of the reasons forks like neovim appear. (and unfortunately often you can't "motivate" your way into creating enough time for all that extra work either, so with the best intentions... no it is )

In your first comment you seem to think that the BFDL for life is not so good. Now you are saying negative things about committees. So what do you think would actually be a good way to run an open source project?

> Saying "no" is the easiest job in the world

On the contrary, saying No to an otherwise great contribution that doesn't fit into the longterm vision of a project for one or another reason is the hardest thing in the world.

Many of the Vim nerds I know, including myself, have switched over to Neovim. Only when using a remote server with a default installation do I use regular old Vim.

Neovim sounded like a good idea, so I switched, too. Then after an update, it broke mouse selection in terminal, by turning on some crazy option by default. I still have to search how to disable it each time. Ok, things like that happen. Then, after another update, it broke terminal update. Like, your screen scrolls up or down a line and the text does not get redrawn correctly. Is it a wezterm issue? Well, the original vim works flawlessly. So do less, top, and any other terminal programs. Except neovim.

No thanks. I dont care how many golden elephants are in the trunk if I cannot drive it.

Vim is more stable simply because it changes less often. Neovim is constantly improving its APIs, and that can break stuff. If you don't want to deal with breaking changes, just don't update. You can still use most plugins.

Breaking changes and mistakes are orthogonal to changes to defaults and changes for no clear reason. This separates stable software from perpetual “nightly” one. With Vim you can update through a couple major versions before even realizing it. For me it usually happens after system crashes (classic reinstall windows twice a decade) and the vim config and my habits just work with a new vim download.

If neovim thought that something was broken, it was a very valid reason for a quick change. That’s how changes are made and I think most Vimers respect that. It was a proper community fork, almost a textbook example despite the initial buzz. Everyone got what they needed.

But if you refuse to update, it’s a clear signal for ideological mismatch. The usual issue with picking pace, as I see it through years, is that there’s often no clear finish line where you switch to walking again. The pace just stays like that forever and people start to grow tired of changes they were happy about.

Will that kill Neovim? I don’t think so. People who migrated to it (opposed to newcomers) were built for a change too and will probably “survive” all that. Is your method of dealing with it valid? In principle I agree, nothing wrong with that either.

How do you propose I update my distro (fedora) and just don't update text editor? Are you in a habit of bringing a chroot with known good versions of your tools to every computer you ssh into? Like, I'd really want to have that. May it be I've missed some new thing that allows me to not update?

Don't install neovim with your system package manager, just like your other development tools. If you rely on a tool where the version makes a big difference, you should be in control of it, not the system package manager. You can build it from the source (which works fine) or use something like Bob [1].

[1]https://github.com/MordechaiHadad/bob

/usr/local/bin

Neovim sort of reminds me of zsh, in the sense that I can never really figure out if there’s some underlying technical advantage or if it is just the case that some features people like have been turned on by default.

Not that I disagree that both Zsh and Neovim turn on some attractive features by default, but the `zle` line editor being more extensible than deadline and built-in support Treesitter/LSP support seem like pretty obvious technical advantages (for the folks the features those enable are attractive to).

Fellow wezterm user here, I occasionally have redraw issues with neovim, maybe once a month of heavy use. Whatever happened to ^L to redraw the screen, it seems to no longer work...

I've moved away from maintaining my own vimrc, and towards vim distributions, and they all seem to be neovim targeted. First it was LunarVim, and more recently after Lunar stopped being maintained to AstroVim. They have been quite good at batteries included vim, and I'll never go back to vim without LSP.

Do you have your terminfo set up properly? I used to experience bad glitching when working with vertical splits, but it went away once I applied this. https://wezfurlong.org/wezterm/config/lua/config/term.html

My TERM is set to xterm-256color.

Does this imply that Vim has no LSP support? Cause ALE is a Vim-spirited zeroconf-ish LSP bridge for those who don’t know.

Base vim does not have LSP built in, AstroVIM is a packaging of a bunch of plugins that includes the LSP plugins and more.

This was my experience. Couldn't get into Vim, and once so got used to Neovim it broke. :(

I really love the Helix editor, and haven't had these issues yet, but it's not intended as a 1-1 vim replacement.

I've also seen terminal misbehaviour with neovim, not using wezterm, including incredibly slow redraws.

I have tried several times and I always switched back to vanilla vim. Neovim has various nice features but it requires a lot of time to migrate correctly IMHO. 20 years of habits are hard to leave, I think.

Sure the configuration file is retro compatible, but some of the plugins are better suited for neovim and vice versa. I use a dozen of them and if I switch permanently to neovim I'd like to start fresh using more "modern" alternatives that make use of the newer features.

I found the neovim community to operate a bit like the node ecosystem, you pull in a plugin for every problem that solves already solved problems their own way. The plugins are also very flashy with tons of animations, colors and emojis, which to me is just distracting. That said I think people should use what they like, and I am happy that there is a big community developing an alternative to VSCode. I just didn't feel it was for me.

I ended up moving to Kakoune. The community is small but the tool is so much better designed and integrates well with unix. That means that i can usually glue together whatever I need myself with 1-3 lines of config and don't need an entire plugin when I want something that isn't built-in.

> The plugins are also very flashy with tons of animations, colors and emojis, which to me is just distracting

I also have seen that the very first time I tried neovim. Some people may like it but I consider a terminal to be as simple as possible. Furthermore, I use often the CLI on non-GUI terminals where such non-ASCII characters can have various side effects (e.g. unicode bars, braille like progress bar and so on, those destroy your serial terminal line).

The Unix integration is so very good. I have keybinds to fmt for line wrapping and date to insert timestamps, and I like being able to pipe a selection to dc to do some quick math. It’s so easy, I do it without even thinking about it.

> The plugins are also very flashy with tons of animations, colors and emojis, which to me is just distracting.

I don't think I've seen plugins with animations (nor would I want to). Agreed that emoji in the terminal, modulo useful glyphs like language logos next to files in a directory tree [0], are distracting.

What I don't understand are people who add a million plugins, and then wonder why the startup performance is terrible. I have a fair amount, including some I honestly rarely or never need, and startup time is still 75 msec, which is fast enough for me not to be bothered.

[0]: https://github.com/ms-jpq/chadtree

When I migrated years ago (mostly to get access to some plugins), nvim gladly swallowed my old configuration with no changes. Then I could change to lua and other modern features at my own pace.

By "swallowed", I thought you meant that Neovim silently deleted your files. I'm glad the context makes it clear that it didn't.

…I still haven’t switched to lua, all I need still works fine

I went back and forth quite a lot until i decided to stick to vim. The reason being that I want to gain deep knowledge of my editor instead of depending on a gazillion plugins that occasionally break. Now, I understand this is something you can do with both vim and neovim, however the documentation of neovim is littered with both the vim docs and the new lua docs, and there is a vibe of "you already know all of vim, here is the lua equivalent", which made it very inaccessible to me. I decided I'll spend the time in the more simple editor of the two and maybe reevaluate this decision again in 3-4 years

I did the same. I mostly use Vim without plugin and a simple vimrc file. For the heavy stuff and big projects I use VSCode.

I still use a bloated version of vim for my day job, since it involves huge react+ts apps. But i slowly build up a clean vimrc while writting my pet projects

:s/VSCode/Jetbrains/

Wow!

Neovim turned itself into a pop-blink IDE which some people never wanted. It's good that it serves the needs of its fans, but it's also good that Vim stayed in its own tracks. Losing Vim as it is would be a great loss for many.

With no config file Neovim is just vim but with mouse mode enabled by default. With Lua and the new APIs it’s much easier to write powerful plugins that do crazy shit and use animation but none of that happens by default, you need to go out of your way to get that kind of action, same as with regular vim.

It's not, though. A bunch has been stripped out (interactive :!, :view, etc) and time only time will tell how much further they will drift apart.

And as such neovim has dropped POSIX conformance (including things like `:!` as you mention, that I use regularly) and is apparently not interested in it.

I wanted to like neovim for its possibly better lsp integration, but if all I need is an IDE with partial vi emulation, I might as well use VSCode.

It's true that there are minor differences but 99% of the experience is the same, with Vimscript and Vim plugins alike.

Thanks for that. I was thinking of trying NeoVim but I regularly use the `:!` feature to filter (selected) text through Unix utilities – and `:view` if I forget to use the `-R` option when opening a file that I don’t want to accidentally edit, e.g., log files.

:! itself has not been stripped from neovim, it's the "interactive" :! that has been stripped (as the OP said)

i.e if you do :!bash in vim you enter bash in neovim you won't

Thanks for the clarification. That makes sense and seems like a reasonable change to me.

I wouldn't say that `:!bash` is the most illustrative example of its impact. It bites you when you run any command that spits out a prompt, most commonly a [Yn] prompt. You can't use `:!` for these in nvim.

I'm glad I'm not the only one who thinks the same thing.

I also think that "stability" and the "community" are two other things that made me switch back to vim.

What does 'pop-blink' mean in this context?

Something pops out and blinks on itself while you are typing. At least that's what I've seen in neovim "ads" videos back in the day.

Very annoying. I decided to move from manually creating my own config to using Astronvim and there were just so many distracting things in the default installation. The good thing is that you can disable what you don't want - which I did. The bad thing is that finding the right option or the actual plugin that is bringing the functionality you don't want takes some time.

Was the prebuilt configuration worth it in the end then? I recently started a from-scratch config and followed kickstart, which is pretty minimal and also not a plugin/distribution/self-updating thing, it’s just an example config file you can copy.

Yeah. Once you understand the configuration it's really nice, it is also well documented.

A good option is to start with kickstart.nvim. This allows you to build up from a very basic install, or keep the simple default install without a lot of plugins.

I just set up a Neovim configuration from scratch and I have no idea what you are talking about. I did install a completion plugin literally called blink, but even that supports keybinding activation.

My transition was unsuccessful for a differrent reason, although I still think that while being open to change, it’s ideologically correct to stay with ideas you are aligned with.

When I tried it, nvim-qt was hard to associate with file extensions on windows (required something like “-- “filename”” in different shapes and hours of regedit debugging, can’t remember now), then nvim itself had issues with refreshing on manual window resize and with autoresizing the window on setting ‘lines’. And a few more os integration related issues. It was basically unusable gui-wise so I bailed out due to no good reason to stay.

I was probably talking about that astro-thing that works like a christmas tree and was the main selling point at the time.

> Neovim turned itself into a pop-blink IDE

What does that even mean? Just sounds like a lazy and false argument.

It was a selling point back then and the reason for a fork. Bram didn’t want to add async tech into Vim, cause async enabled various parallel-to-you visual activities. Neovim forked and did async+lua on its own terms. Vim later added async functionality, and I think it was the best outcome. Vimers still got shy LSPs and Neovimers got whatever they dreamed about in their separate emvironment. Good fork.

Things may have settled since then, maybe that’s why you think that this phrase looks odd.

Async is only a performance detail and using a degorary term as "pop-blink IDE" to refer to the choice to include async is wrong.

I've been using Neovim since it forked and it has always offered a Vim-like experience, it's just that Neovim has given you more options.

Maybe that's why some think it's too "blinky" as it's possible to turn it into a blinky IDE if you really want to because it's more capable (and some do).

What were these options? Something must have been very special to make a fork and not just a set of plugins. What was it, in terms of end-user features?

The feature I migrated for was async update and installation of plugins, and I used Neovim exactly as I used Vim a long time after that.

It's just in recent years I've migrated to Lua and the large amount of Neovim specific plugins (many that heavily depend on async for non-blocking operation of for instance picking or completion).

From the Stack Overflow survey:

https://news.ycombinator.com/item?id=42811182

    Vim 21.6%
    Neovim 12.5%

I wonder what it looked like in prior years.

I’m willing to believe that “vim” combines some neovim users, but I’m not surprised that the original is still more popular. Anecdotally vim seems to ship new features faster than it did 3 years ago.

Braam really took Neovim personally and got better at getting stuff into vim that he wouldn't merge before once neovim was arround as a competitor. I really lost track of vim in the last years because neovim is just a solid platform with an active community.

But honestly at work, I think I am the only one using either a vim or emacs (I kind of use neovim and emacs but primarily neovim). In my childhood there was a TV series called "The last of his class" and it really showed old people (retirement age) doing jobs that will be gone once their retire. While some jobs truly vanished, others just transformed so drastically that they cannot be likened anymore to the job those folks did. Anyway, I feel we are watching changes in developer tooling that will be seen as the end of an era.

* https://de.wikipedia.org/wiki/Der_Letzte_seines_Standes%3F

Why do Neovim users feel the need to take down Bram and Vim? Now you are taking credit for Bram's work!

Why not make an application you love and leave everyone else alone? The community's behavior - what I see - is a deterrent to using Neovim.

> Now you are taking credit for Bram's work!

That’s a baseless accusation. I’ve been using Vim for about 25 years, and over the years have contributed small changes to some of the default plugins maintained by third parties (mostly language syntax and `filetype` configuration files). I have yet to even try Neovim but I too noticed that the rate of minor version releases and new features in Vim had increased after the Neovim project got off the ground.

It's not at all baseless - the basis is the parent (now GGP) comment, even if you disagree with the analysis.

It’s astonishing that you can arrive at this conclusion from my comment. He did great work, his development process did not scale. I am happy that I was able to use vim for more than a decade prior to neovim. The fact that after the neovim fork vims development started to pick up speed again is a fact (and doesn’t devalue bram’s work in any way).

I am happy with bram’s work on vim and with the neovim devs and their work on neovim.

> his development process did not scale

I hope my development projects fail like Moolenaar's! Vim has been extraordinarily successful for decades, possibly the top 5 or 10 FOSS projects ever (?). Citing Vim as an example of development process failure is really incredible.

Again, it is not a failure of him or his project that his development process heavily relied on him reviewing, modifying and merging patches and that he at times did not commit time to do that. He was not obliged to do more than what he did and vim was indeed very successful.

However, it is also very understandable why vim was forked by the neovim devs, in my view it has been a great success. That doesn't diminish Bram Molenaars achievements and contributions to the world.

I would prefer to use vim, but most plugins are limited to neovim these days. I also feel the overall speed of neovim is better and less janky when interacting with buffers and navigating files.

The treesitter highlighting in neovim is also better/supports more files out of the box than vim. In vim I was far too used to syntax highlighting being broke halfway through a file for one reason or another (lines too long, syntax new or broken, etc).

I dislike setting up neovim, but I also dislike vim's heavy use of language specific plugins. In a perfect world I'd have lsp+treesitter in vim out of the box and no need to install any plugins.

People who describe themselves as "vim nerds" might not be representitive of the average vim user.

Maybe, but it's hard to be a vim user without being somewhat of a vim nerd. At least you have to understand a new concept of interface, several modes, and lots of keyboard shortcuts - that would make you a nerd in any other application.

Maybe, but i use vim everyday. I have no intention of switching to neovim simply because i don't know what the difference even is. There are levels to vim usage, and you can still be very productive while only knowing the basic keyboard shortcuts.

That is the only reason why while being on Emacs side, on the whole Emacs vs vi, I ended up learning enough vi to be productive on customers' UNIX systems.

I switched to VSCode with vim mode. I think it's a good tradeoff to get IDE features with modal editing.

Did you use the Vim or the Neovim plugin? I have had a hard time trying to get either to play nice with VSCode.

I use VSCodeVim. I have used for a while without trouble. There are some issues, for instance, bookmarks don't work for me. Never tried neovim.

> How can we make Vim9 script, the new Vim scripting language, more widely used?

One way is to inform users and prospective plugin writers that

1) Vim9 script is vastly superior to the old Vimscript, to the point where it is not unpleasant to use, and

2) it is much more conductive to writing text editor code than the general purpose Lua.

Of course this still does not mean that people will want to learn yet another scripting language to write Vim plugins in particular when they already know Lua, but it is very important to be adequately informed about the two above points.

> it is much more conductive to writing text editor code than the general purpose Lua.

Lua is very much not a general-purpose Language. It can be used like one, but it's a specialized language thought to live inside a "host" application, which it then controls. Which does seem to fit the usecase here.

Would you be able to substantiate your claim that it is more conductive to text editor code?

> it is not unpleasant to use

I'm afraid that is a very low bar. Lua is not unpleasant to use either.

No, I don't feel like substantiating my claims to someone who assumes a default hostile response to me and makes nonsensical readings of what I say.

For instance, when I compare Lua to vim9 script and say the former is general purpose, I am obviously in the context of comparing the one scripting language to the latter. And you know that. And yet, even though you understand the context perfectly, you still choose to write "Lua is very much not a general-purpose Language..." and proceed to patronize me on semantics.

So, will I be able to substantiate? Yes. Will I bother to do so to you? No.

I don't know how my comment as hostile. But sure, don't substantiate.

It's hostile, and GP did basically substantiate by pointing out the strawman.

Sure, by editing their comment after wrote mine. I don’t really care at this point guys. Have a nice day and enjoy your language.

Thank you; have a great day as well.

Vim is not my cup of tea actually. I live in eMacs.

Speaking purely technically here, vim9/L has an actual standard library tailored specifically to Vim. Lua has no standard library and you just end up delegating to vimscript anyway. But ya, if you want to use Lua for whatever reason then it's a pretty hard sell. But that's sorta what OP is getting at... how to make it more attractive.

> Of course this still does not mean that people will want to learn yet another scripting language

I understand this sentiment and that there are certainly psychological blockers in having to learn too many languages, but vim9 is very simple to learn. It is much closer to a "familiar" language than Lua. Plus, you are going to have to be familiar with Vim's standard library anyway. I believe they are adding more and more helper functions but Lua plugins are full of `vim.cmd` and `vim.fn`. I don't dislike Lua as a language at all, but I much prefer "scripting Vim" in some sort of "VimScript" :) But to each their own.

I agree completely.

> it is much more conductive to writing text editor code than the general purpose Lua.

Personally I think that was already the case with "classic" VimScript, although I also appreciate it's a bit idiosyncratic and that many people don't have the time or interest to learn it.

I suppose that's also the problem with VimScript9. I agree is a real and meaningful improvement over VimScript, but I suppose that for many it's just "not important enough" to learn, even though it's not an especially difficult language to learn. I don't think that's unreasonable – there's tons of not especially difficult things I never bothered to learn in depth either, I just happened to choose Vim stuff at some point.

Honestly supporting a language is a lot of work. Documentation, language servers, ramping time for users to learn it, etc. I find it hard to believe vimscript9 is worth it over lua. I've seen the ecosystem for neovim seem to thrive, and in part because it looks like lua is a lower barrier language, especially if you've used it outside of vim.

The aggregate value of each soul that goes away is staggering. Bram is a good example; his work in VIM and his help to children in need will be sorely missed. I wish we were doing more to break that cycle.

I wonder how long vim and emacs can stay vibrant. I've used emacs in the last 20 years, so I stick with it, but new generations who are trained on vscode and such are less likely to use such "old fashioned" tools.

Surely, there will still be emacs and vim users 50 years from now, but the user numbers and the community power will diminish as the graybeards gradually leave this plane.

You can't really compare vim and emacs beyond a superficial level.

Emacs is fundamentally an interactive shell, like Bash. It has a text editor, also like Bash. It is of course generally more powerful and featureful than Bash.

Hence, people sometimes live in Emacs, because it's a shell like Bash or Gnome or KDE.

I use Emacs and VSCode. VSCode for some code repos, and Emacs for general computer usage.

Meanwhile, Vim is a text editor. It is neither a shell nor an IDE, although it can be adapted somewhat into an IDE.

I also use vi (alongside Emacs and VSCode). vi is for editing some text if I am not in Emacs for some reason or if I temporarily borked my Emacs config.

(I also use ed, for when I'm in a dumb terminal or I don't want to lose screen context.)

Vim or Emacs "dying" is not really an issue, although Vim or Emacs losing enough mindshare to keep them up to date as competitive IDE options, maybe that might happen.

Just for the other side of the picture, I live in vim and use it as my terminal multiplexer. Vim’s my shell. I have thousands of buffers in vim and practically never leave it. I’ve used terminal multiplexers for years before I switched to vim in that capacity and never looked back. The integration it’s allowed between all my buffers and commands and shells is difficult to match in my opinion.

As a 3rd anecdote, I used vim for 10 years as my primary editor and “shell”. Then 10 years ago I learned tmux and fell in love with its window multiplexing. Now I use vim strictly as an editor/splitter. But I use tmux to split my code from my repl window. And maintain multiple windows where I’m working on different projects.

I'm going to try this. I use tmux but the idea of being able to use vim for everything seems nice. If you have tips/suggestions, I'm interested.

For me, some of the things that's really important for a terminal multiplexer include:

1) Keybindings having no conflicts with other terminal applications. For that, vim's default window-management key of <C-w> is unfortunate, as it is very important for delete words in bash and readline. I remap that to <C-@> (CTRL-Space) instead, which is basically used by no terminal program that I am aware of. The other key binding that trips me up are the default vim keybindings to kill the terminal (<C-w><C-c>). If I am midway attempting a window action, but realise something is taking too long and want to stop the job, the keybinding kills my whole shell. If I really want to kill my terminal, I can always issue ZQ or :q! in normal mode.

2) Change my cursor shapes based on which mode I'm in (normal, insert, or terminal/command), which helps me easily tell the mode.

3) Improve the default keybinding for going from terminal back to terminal normal mode. I find the default keybindings <C-\><C-n> and <C-w>N too difficult to type because I need to use this binding very much.

4) Be able to move between windows with the same, consistent set of keybindings no matter which mode I'm in (e.g. not having to go back to normal mode first, from insert or terminal mode). In the same vein, when I land on a buffer I always expect to be in normal mode, so I can start moving around immediately and yank stuff without remembering whether I'm in a terminal or a non-terminal buffer. When I need to manipulate the terminal program I can always `i` or `a`.

I have quite a few other customisations to my vim terminal, but I think these are the most essential ones.

vimrc for 1)

    set termwinkey=<C-@>
    noremap <C-@> <C-w>
    noremap <C-@><CR> <C-w><CR>
    noremap! <C-@> <Esc><C-w>

    noremap <C-@>c <Nop>
    noremap <C-@><C-c> <Nop>
    noremap <C-@><C-q> <Nop>
    noremap! <C-@>c <Nop>
    noremap! <C-@><C-c> <Nop>
    noremap! <C-@><C-q> <Nop>
    tnoremap <C-@>c <Nop>
    tnoremap <C-@><C-c> <Nop>
    tnoremap <C-@><C-q> <Nop>
    noremap <C-@>q <Nop>
    noremap! <C-@>q <Nop>
    tnoremap <C-@>q <Nop>

vimrc for 2) and 3)

    augroup term_normal
     au!      
     autocmd WinNew * let w:winnew = 1
     autocmd CmdlineEnter * let w:outcmd = 0
     autocmd CmdlineLeave * let w:outcmd = 1
     autocmd WinEnter * if exists ('w:winnew') | unlet w:winnew | if (mode() == 't') | call Termcursor () | endif | elseif get(w:, 'outcmd', 1) && (mode() == 't') | call feedkeys("\<C-@>N", "") | endif
     autocmd WinLeave * if (mode() == 't') && (! exists('w:tu')) | call feedkeys("\<C-@>N", 'x') | call Normalcursor () | elseif (mode(1) == 'nt') && (exists('w:tu')) | call feedkeys("i", 'ix') | endif

     tmap <expr> <C-@><C-@> ((mode() == 't') && get(w:, 'outcmd', 1)) ? '<C-@>N' : '<C-@><C-@>'
     augroup end
    
    let &t_SI = "\e[6 q\e]12;#FF00DF\<C-g>"
    let &t_EI = "\e[2 q\e]12;#FF00DF\<C-g>"
    let &t_ti = "\e[4 q\e]12;#FF00DF\<C-g>"
    let &t_te = "\e[2 q\e]12;#FF00DF\<C-g>"
    let &t_Us = "\e[4:2m"
    let &t_ds = "\e[4:4m"
    let &t_Ds = "\e[58:5:4m\e[4:5m"
    
    function! Normalcursor ()
     let &t_ve ="\e[2 q\e]12;#FF00DF\<C-g>" 
     let &t_vi ="\e[2 q\e]12;#FF00DF\<C-g>"
     endfunction
    function! Echonormalcursor ()
     call echoraw("\e[2 q\e]12;#FF00DF\<C-g>")
     endfunction
    function! Termcursor ()
     let &t_ve ="\e[4 q\e]12;#FF00DF\<C-g>"
     let &t_vi ="\e[4 q\e]12;#FF00DF\<C-g>"
     endfunction
    function! Echotermcursor ()
     call echoraw("\e[4 q\e]12;#FF00DF\<C-g>")
     endfunction
    
    augroup termcursor
     au!
     autocmd ModeChanged *:n* let &t_ve ="\e[2 q\e]12;#FF00DF\<C-g>"
     autocmd ModeChanged *:n* let &t_vi ="\e[2 q\e]12;#FF00DF\<C-g>"
     autocmd ModeChanged i:* if &t_ve == "" | let &t_ve ="\e[2 q\e]12;#FF00DF\<C-g>" | endif
     autocmd ModeChanged i:* if &t_vi == "" | let &t_vi ="\e[2 q\e]12;#FF00DF\<C-g>" | endif
     autocmd ModeChanged *:i* let &t_ve =""
     autocmd ModeChanged *:i* let &t_vi =""
     autocmd ModeChanged *:t call echoraw("\e[4 q\e]12;#FF00DF\<C-g>")
     autocmd ModeChanged *:t let &t_ve ="\e[4 q\e]12;#FF00DF\<C-g>"
     autocmd ModeChanged *:t let &t_vi ="\e[4 q\e]12;#FF00DF\<C-g>"
     autocmd ModeChanged t:* call echoraw("\e[2 q\e]12;#FF00DF\<C-g>")
     autocmd ModeChanged t:* if (mode(1) != 'ct') | let &t_ve ="\e[2 q\e]12;#FF00DF\<C-g>" | endif
     autocmd ModeChanged t:* if (mode(1) != 'ct') | let &t_vi ="\e[2 q\e]12;#FF00DF\<C-g>" | endif
    
     let g:cmdlinedepth = 0
     autocmd CmdlineEnter * let g:cmdlinedepth = g:cmdlinedepth + 1 | let &t_ve = "\e[4 q\e]12;#FF00DF\<C-g>" | let &t_vi = "\e[4 q\e]12;#FF00DF\<C-g>"
     autocmd CmdlineLeave * let g:cmdlinedepth = g:cmdlinedepth - 1 | if g:cmdlinedepth == 0 | if (mode(1) == 'ct') | call Termcursor () | else | call Normalcursor () | endif | endif
     autocmd CmdwinEnter * let &t_ve ="\e[2 q\e]12;#FF00DF\<C-g>" | let &t_vi ="\e[2 q\e]12;#FF00DF\<C-g>"
     autocmd CmdwinLeave * let &t_ve = "\e[4 q\e]12;#FF00DF\<C-g>" | let &t_vi = "\e[4 q\e]12;#FF00DF\<C-g>"
     
     " autocmd WinEnter * call echoraw("\e[2 q\e]12;#FF00DF\<C-g>")

vimrc for 4)

    vnoremap <C-@>s <C-w>sgv
    vnoremap <C-@>v <C-w>vgv

    nnoremap <expr> <C-@>w '@_' .. ((v:count1 + (winnr() - 1)) % (winnr('$')) + 1) .. '<C-w>w'
    nnoremap <expr> <C-@>W '@_' .. (((- v:count1 + (winnr() - 1)) % (winnr('$')) + winnr('$')) % (winnr('$')) + 1) .. '<C-w>w'
    nnoremap <expr> <C-@>t '@_' .. ((v:count1 - 1) % (winnr('$')) + 1) .. '<C-w>w'
    nnoremap <expr> <C-@>b '@_' .. (((- v:count1) % (winnr('$')) + winnr('$')) % (winnr('$')) + 1) .. '<C-w>w'
    inoremap <C-@><C-@> <C-@>
    map! <C-@>w <Esc><C-@>w
    map! <C-@>W <Esc><C-@>W
    map! <C-@>t <Esc><C-@>t
    map! <C-@>b <Esc><C-@>b
    tmap <C-@>w <C-@>N<C-@>w
    tmap <C-@>W <C-@>N<C-@>W
    tmap <C-@>t <C-@>N<C-@>t
    tmap <C-@>b <C-@>N<C-@>b

Some other things I do:

Invoke terminals on directories (instead of netrw). So, I can e.g. sp. to split to a new terminal.

  function! Isdir(dir) abort
   return !empty(a:dir) && (isdirectory(a:dir) ||
    \ (!empty($SYSTEMDRIVE) && isdirectory('/'..tolower($SYSTEMDRIVE[0])..a:dir)))
   endfunction
  
  augroup terminal-explorer
   au!
   au VimEnter * sil! au! FileExplorer *
   au VimEnter * sil! au! Network *
   au VimEnter * sil! au! AuNetrwEvent *
   " au FileType netrw cd % | bw | exe 'terminal ++curwin'
   au BufEnter * if &filetype != 'netrw' && Isdir(expand('%')) | lcd % | exe bufnr("%") ..'bufdo terminal ++curwin' | endif
   augroup end

Make <C-@>m close windows instead:

    noremap <C-@>m <C-w>c
    noremap! <C-@>m <Esc><C-w>c
    tnoremap <C-@>m <C-@>c

Make <C-@>p find the next window if there is no previous window:

    noremap <expr> <silent> <C-@>p ':<C-u>wincmd p <Bar> if win_getid () == ' .. win_getid () .. ' <Bar> wincmd w <Bar> endif <CR>'
    noremap! <expr> <silent> <C-@>p '<Esc>:<C-u>wincmd p <Bar> if win_getid () == ' .. win_getid () .. ' <Bar> wincmd w <Bar> endif <CR>'
    tnoremap <expr> <silent> <C-@>p '<C-@>:<C-u>wincmd p <Bar> if win_getid () == ' .. win_getid () .. ' <Bar> wincmd w <Bar> endif <CR>'

Use <C-@>~. to detach the GNU screen that my vim is running in (I put my vim in a screen with `unbindall` i.e. I use screen merely for keeping my vim alive) (<C-@>~. is in analogy to the SSH quit keybinding <CR>~.).

    noremap <expr> <silent> <C-@>~. ':<C-u>silent !screen -X detach<CR>'
    noremap! <expr> <silent> <C-@>~. '<C-@>:<C-u>silent !screen -X detach<CR>'
    tnoremap <expr> <silent> <C-@>~. '<C-@>:<C-u>silent !screen -X detach<CR>'

With gf and gF, opening files just from a terminal grep is practically more convenient than vim's :grep. For gf in a new tab:

    map <silent> <C-@><C-f> :<C-u>tab split<CR>gf

With terminal multiplexing in vim, you start getting a lot of buffers. You can consider getting a custom tabline. Other tab management features become more important too. You might expect [count]gt to behave just like gt for [count] times:

    nnoremap <expr> gt '@_' .. ((v:count1 + (tabpagenr () - 1)) % (tabpagenr('$') ) + 1) .. 'gt'

For ease of moving to the last tab:

    nnoremap <expr> g<C-t> '@_' .. (((v:count == 0) ? tabpagenr ('$') : v:count)) .. 'gt'

To consistently access the gt family of bindings regardless of mode:

    map <C-@>gt gt
    map <C-@>gT gT
    map <C-@>g<C-t> g<C-t>
    map! <C-@>gt <Esc>gt
    map! <C-@>gT <Esc>gT
    map! <C-@>g<C-t> <Esc>g<C-t>
    tmap <C-@>gt <C-@>Ngt
    tmap <C-@>gT <C-@>NgT
    tmap <C-@>g<C-t> <C-@>Ng<C-t>

When you use <C-w>T a lot to move your windows in to new tabs, you might sometimes want to move them to the previous tab instead of the next one:

    nnoremap <silent> <C-@><C-t> <C-w>T
    nnoremap <silent> <C-@>T <C-w>T:<C-u>tabm -1<CR>

To access these two in any mode consistently:

    map! <C-@><C-t> <Esc><C-@><C-t>
    map! <C-@>T <Esc><C-@>T
    tmap <C-@><C-t> <C-@>N<C-@><C-t>
    tmap <C-@>T <C-@>N<C-@>T

Analogously to gt and gT, sometimes you may want to move your tabs around, or split them:

    function! SSStabmadjust(tabmnum)
     if a:tabmnum < tabpagenr ()
      return a:tabmnum - 1
     else
      return a:tabmnum
      endif
     endfunction

    noremap <silent> <C-@><C-g>s :<C-u>tab split<CR>
    noremap <expr> <silent> <C-@><C-g>t '@_:<C-u>' .. SSStabmadjust ((v:count1 + (tabpagenr () - 1 )) % (tabpagenr('$') ) + 1) .. 'tabm<CR>'
    noremap <expr> <silent> <C-@><C-g>T '@_:<C-u>' .. SSStabmadjust (((- v:count1 + (tabpagenr () - 1 )) % (tabpagenr('$') ) + tabpagenr('$') ) % (tabpagenr('$') ) + 1) .. 'tabm<CR>'
    noremap <expr> <silent> <C-@><C-g><C-t> ':<C-u>' .. ((v:count == 0) ? "" : SSStabmadjust ((v:count % (tabpagenr ('$') )) )) .. 'tabm<CR>'
    map! <C-@><C-g>s <Esc><C-@><C-g>s
    map! <C-@><C-g>t <Esc><C-@><C-g>t
    map! <C-@><C-g>T <Esc><C-@><C-g>T
    map! <C-@><C-g><C-t> <Esc><C-@><C-g><C-t>
    tmap <C-@><C-g>s <C-@>N<C-@><C-g>s
    tmap <C-@><C-g>t <C-@>N<C-@><C-g>t
    tmap <C-@><C-g>T <C-@>N<C-@><C-g>T
    tmap <C-@><C-g><C-t> <C-@>N<C-@><C-g><C-t>

When you get to using [count]g[something] and g[count][something] and <C-@>[count]g[something] etc a lot, you start getting a bit confused about where you need to put the count to make things work. So you can make putting the count anywhere work; now, don't worry and just start pressing g or <C-@>g for window actions, and put a count if you realise you need it:

    map <expr> <C-@>1 Termcountmap(1, "")
    map <expr> <C-@>2 Termcountmap(2, "")
    map <expr> <C-@>3 Termcountmap(3, "")
    map <expr> <C-@>4 Termcountmap(4, "")
    map <expr> <C-@>5 Termcountmap(5, "")
    map <expr> <C-@>6 Termcountmap(6, "")
    map <expr> <C-@>7 Termcountmap(7, "")
    map <expr> <C-@>8 Termcountmap(8, "")
    map <expr> <C-@>9 Termcountmap(9, "")
    map! <expr> <C-@>1 Termcountmap(1, '<Esc>')
    map! <expr> <C-@>2 Termcountmap(2, '<Esc>')
    map! <expr> <C-@>3 Termcountmap(3, '<Esc>')
    map! <expr> <C-@>4 Termcountmap(4, '<Esc>')
    map! <expr> <C-@>5 Termcountmap(5, '<Esc>')
    map! <expr> <C-@>6 Termcountmap(6, '<Esc>')
    map! <expr> <C-@>7 Termcountmap(7, '<Esc>')
    map! <expr> <C-@>8 Termcountmap(8, '<Esc>')
    map! <expr> <C-@>9 Termcountmap(9, '<Esc>')
    tmap <expr> <C-@>1 Termcountmap(1, '<C-@>N')
    tmap <expr> <C-@>2 Termcountmap(2, '<C-@>N')
    tmap <expr> <C-@>3 Termcountmap(3, '<C-@>N')
    tmap <expr> <C-@>4 Termcountmap(4, '<C-@>N')
    tmap <expr> <C-@>5 Termcountmap(5, '<C-@>N')
    tmap <expr> <C-@>6 Termcountmap(6, '<C-@>N')
    tmap <expr> <C-@>7 Termcountmap(7, '<C-@>N')
    tmap <expr> <C-@>8 Termcountmap(8, '<C-@>N')
    tmap <expr> <C-@>9 Termcountmap(9, '<C-@>N')

    function! Termcountmap(initcount, normalkeys)
     let termcount = a:initcount
     while 1
      try
       let char = getchar()
      catch /^Vim:Interrupt$/
       return ""
       endtry
    
      if type(char) == 0
       let char = nr2char(char)
       endif
    
      if char == '0'
       let termcount = termcount * 10
      elseif char == '1'
       let termcount = termcount * 10 + 1
      elseif char == '2'
       let termcount = termcount * 10 + 2
      elseif char == '3'
       let termcount = termcount * 10 + 3
      elseif char == '4'
       let termcount = termcount * 10 + 4
      elseif char == '5'
       let termcount = termcount * 10 + 5
      elseif char == '6'
       let termcount = termcount * 10 + 6
      elseif char == '7'
       let termcount = termcount * 10 + 7
      elseif char == '8'
       let termcount = termcount * 10 + 8
      elseif char == '9'
       let termcount = termcount * 10 + 9
      elseif char == 'g'
       return a:normalkeys .. termcount .. 'g'
      elseif char == "\<C-g>"
       return a:normalkeys .. termcount .. "\<C-@>\<C-g>"
      elseif char == 'w'
       return a:normalkeys .. termcount .. "\<C-@>w"
      elseif char == 'W'
       return a:normalkeys .. termcount .. "\<C-@>W"
      elseif char == 't'
       return a:normalkeys .. termcount .. "\<C-@>t"
      elseif char == 'b'
       return a:normalkeys .. termcount .. "\<C-@>b"
      else
       return a:normalkeys .. ":\<C-u>" .. termcount .. ' wincmd ' .. char .. "\<CR>\<C-l>"
       endif
    
      endwhile
     endfunction
    
    map <expr> g<C-@> <C-@>g
    
    map <expr> g1 Prefixcountmap (v:count * 10 + 1, "", 'g')
    map <expr> g2 Prefixcountmap (v:count * 10 + 2, "", 'g')
    map <expr> g3 Prefixcountmap (v:count * 10 + 3, "", 'g')
    map <expr> g4 Prefixcountmap (v:count * 10 + 4, "", 'g')
    map <expr> g5 Prefixcountmap (v:count * 10 + 5, "", 'g')
    map <expr> g6 Prefixcountmap (v:count * 10 + 6, "", 'g')
    map <expr> g7 Prefixcountmap (v:count * 10 + 7, "", 'g')
    map <expr> g8 Prefixcountmap (v:count * 10 + 8, "", 'g')
    map <expr> g9 Prefixcountmap (v:count * 10 + 9, "", 'g')
    tmap <expr> <c-@>g1 Prefixcountmap (v:count * 10 + 1, '<c-@>n', 'g')
    tmap <expr> <c-@>g2 Prefixcountmap (v:count * 10 + 2, '<c-@>n', 'g')
    tmap <expr> <c-@>g3 Prefixcountmap (v:count * 10 + 3, '<c-@>n', 'g')
    tmap <expr> <c-@>g4 Prefixcountmap (v:count * 10 + 4, '<c-@>n', 'g')
    tmap <expr> <c-@>g5 Prefixcountmap (v:count * 10 + 5, '<c-@>n', 'g')
    tmap <expr> <c-@>g6 Prefixcountmap (v:count * 10 + 6, '<c-@>n', 'g')
    tmap <expr> <c-@>g7 Prefixcountmap (v:count * 10 + 7, '<c-@>n', 'g')
    tmap <expr> <c-@>g8 Prefixcountmap (v:count * 10 + 8, '<c-@>n', 'g')
    tmap <expr> <c-@>g9 Prefixcountmap (v:count * 10 + 9, '<c-@>n', 'g')
    
    map <expr> <C-@><C-g>1 Prefixcountmap (v:count * 10 + 1, "", '<C-@><C-g>')
    map <expr> <C-@><C-g>2 Prefixcountmap (v:count * 10 + 2, "", '<C-@><C-g>')
    map <expr> <C-@><C-g>3 Prefixcountmap (v:count * 10 + 3, "", '<C-@><C-g>')
    map <expr> <C-@><C-g>4 Prefixcountmap (v:count * 10 + 4, "", '<C-@><C-g>')
    map <expr> <C-@><C-g>5 Prefixcountmap (v:count * 10 + 5, "", '<C-@><C-g>')
    map <expr> <C-@><C-g>6 Prefixcountmap (v:count * 10 + 6, "", '<C-@><C-g>')
    map <expr> <C-@><C-g>7 Prefixcountmap (v:count * 10 + 7, "", '<C-@><C-g>')
    map <expr> <C-@><C-g>8 Prefixcountmap (v:count * 10 + 8, "", '<C-@><C-g>')
    map <expr> <C-@><C-g>9 Prefixcountmap (v:count * 10 + 9, "", '<C-@><C-g>')
    map! <expr> <C-@><C-g>1 Prefixcountmap (v:count * 10 + 1, '<Esc>', '<C-@><C-g>')
    map! <expr> <C-@><C-g>2 Prefixcountmap (v:count * 10 + 2, '<Esc>', '<C-@><C-g>')
    map! <expr> <C-@><C-g>3 Prefixcountmap (v:count * 10 + 3, '<Esc>', '<C-@><C-g>')
    map! <expr> <C-@><C-g>4 Prefixcountmap (v:count * 10 + 4, '<Esc>', '<C-@><C-g>')
    map! <expr> <C-@><C-g>5 Prefixcountmap (v:count * 10 + 5, '<Esc>', '<C-@><C-g>')
    map! <expr> <C-@><C-g>6 Prefixcountmap (v:count * 10 + 6, '<Esc>', '<C-@><C-g>')
    map! <expr> <C-@><C-g>7 Prefixcountmap (v:count * 10 + 7, '<Esc>', '<C-@><C-g>')
    map! <expr> <C-@><C-g>8 Prefixcountmap (v:count * 10 + 8, '<Esc>', '<C-@><C-g>')
    map! <expr> <C-@><C-g>9 Prefixcountmap (v:count * 10 + 9, '<Esc>', '<C-@><C-g>')
    tmap <expr> <C-@><C-g>1 Prefixcountmap (v:count * 10 + 1, '<C-@>N', '<C-@><C-g>')
    tmap <expr> <C-@><C-g>2 Prefixcountmap (v:count * 10 + 2, '<C-@>N', '<C-@><C-g>')
    tmap <expr> <C-@><C-g>3 Prefixcountmap (v:count * 10 + 3, '<C-@>N', '<C-@><C-g>')
    tmap <expr> <C-@><C-g>4 Prefixcountmap (v:count * 10 + 4, '<C-@>N', '<C-@><C-g>')
    tmap <expr> <C-@><C-g>5 Prefixcountmap (v:count * 10 + 5, '<C-@>N', '<C-@><C-g>')
    tmap <expr> <C-@><C-g>6 Prefixcountmap (v:count * 10 + 6, '<C-@>N', '<C-@><C-g>')
    tmap <expr> <C-@><C-g>7 Prefixcountmap (v:count * 10 + 7, '<C-@>N', '<C-@><C-g>')
    tmap <expr> <C-@><C-g>8 Prefixcountmap (v:count * 10 + 8, '<C-@>N', '<C-@><C-g>')
    tmap <expr> <C-@><C-g>9 Prefixcountmap (v:count * 10 + 9, '<C-@>N', '<C-@><C-g>')
    
    function! Prefixcountmap(initcount, prefix, countprefix)
     let termcount = a:initcount
     while 1
      try
       let char = getchar()
      catch /^Vim:Interrupt$/
       return ""
       endtry
    
      if type(char) == 0
       let char = nr2char(char)
       endif
    
      if char == '0'
       let termcount = termcount * 10
      elseif char == '1'
       let termcount = termcount * 10 + 1
      elseif char == '2'
       let termcount = termcount * 10 + 2
      elseif char == '3'
       let termcount = termcount * 10 + 3
      elseif char == '4'
       let termcount = termcount * 10 + 4
      elseif char == '5'
       let termcount = termcount * 10 + 5
      elseif char == '6'
       let termcount = termcount * 10 + 6
      elseif char == '7'
       let termcount = termcount * 10 + 7
      elseif char == '8'
       let termcount = termcount * 10 + 8
      elseif char == '9'
       let termcount = termcount * 10 + 9
      else
       return a:prefix .. termcount .. a:countprefix .. char
       endif
    
      endwhile
     endfunction

(equivalently, if you use screen; the key point is the \eP and the \e\\ between which the real xterm escape codes go, or else screen will eat your escape codes which will never see the light of day)

    augroup term_normal
     au!      
     autocmd WinNew * let w:winnew = 1
     autocmd CmdlineEnter * let w:outcmd = 0
     autocmd CmdlineLeave * let w:outcmd = 1
     autocmd WinEnter * if exists ('w:winnew') | unlet w:winnew | if (mode() == 't') | call Termcursor () | endif | elseif get(w:, 'outcmd', 1) && (mode() == 't') | call feedkeys("\<C-@>N", "") | endif
     autocmd WinLeave * if (mode() == 't') && (! exists('w:tu')) | call feedkeys("\<C-@>N", 'x') | call Normalcursor () | elseif (mode(1) == 'nt') && (exists('w:tu')) | call feedkeys("i", 'ix') | endif
    
     tmap <expr> <C-@><C-@> ((mode() == 't') && get(w:, 'outcmd', 1)) ? '<C-@>N' : '<C-@><C-@>'
     augroup end
    
    let &t_SI = "\eP\e[6 q\e]12;#FF00DF\<C-g>\e\\"
    let &t_EI = "\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\"
    let &t_ti = "\eP\e[4 q\e]12;#FF00DF\<C-g>\e\\"
    let &t_te = "\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\"
    let &t_Us = "\eP\e[4:2m\e\\"
    let &t_ds = "\eP\e[4:4m\e\\"
    let &t_Ds = "\eP\e[58:5:3m\e[4:5m\e\\"
    
    function! Normalcursor ()
     let &t_ve ="\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\" 
     let &t_vi ="\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\"
     endfunction
    function! Echonormalcursor ()
     call echoraw("\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\")
     endfunction
    function! Termcursor ()
     let &t_ve ="\eP\e[4 q\e]12;#FF00DF\<C-g>\e\\"
     let &t_vi ="\eP\e[4 q\e]12;#FF00DF\<C-g>\e\\"
     endfunction
    function! Echotermcursor ()
     call echoraw("\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\")
     endfunction
    
    augroup termcursor
     au!
     autocmd ModeChanged *:n* let &t_ve ="\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\"
     autocmd ModeChanged *:n* let &t_vi ="\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\"
     autocmd ModeChanged i:* if &t_ve == "" | let &t_ve ="\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\" | endif
     autocmd ModeChanged i:* if &t_vi == "" | let &t_vi ="\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\" | endif
     autocmd ModeChanged *:i* let &t_ve =""
     autocmd ModeChanged *:i* let &t_vi =""
     autocmd ModeChanged *:t call echoraw("\eP\e[4 q\e]12;#FF00DF\<C-g>\e\\")
     autocmd ModeChanged *:t let &t_ve ="\eP\e[4 q\e]12;#FF00DF\<C-g>\e\\"
     autocmd ModeChanged *:t let &t_vi ="\eP\e[4 q\e]12;#FF00DF\<C-g>\e\\"
     autocmd ModeChanged t:* call echoraw("\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\")
     autocmd ModeChanged t:* if (mode(1) != 'ct') | let &t_ve ="\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\" | endif
     autocmd ModeChanged t:* if (mode(1) != 'ct') | let &t_vi ="\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\" | endif
     
     " TODO -- doesnt restore from redraw?
     let g:cmdlinedepth = 0
     autocmd CmdlineEnter * let g:cmdlinedepth = g:cmdlinedepth + 1 | let &t_ve = "\eP\e[4 q\e]12;#FF00DF\<C-g>\e\\" | let &t_vi = "\eP\e[4 q\e]12;#FF00DF\<C-g>\e\\"
     autocmd CmdlineLeave * let g:cmdlinedepth = g:cmdlinedepth - 1 | if g:cmdlinedepth == 0 | if (mode(1) == 'ct') | call Termcursor () | else | call Normalcursor () | endif | endif
     autocmd CmdwinEnter * let &t_ve ="\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\" | let &t_vi ="\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\"
     autocmd CmdwinLeave * let &t_ve = "\eP\e[4 q\e]12;#FF00DF\<C-g>\e\\" | let &t_vi = "\eP\e[4 q\e]12;#FF00DF\<C-g>\e\\"
    
     " autocmd WinEnter * call echoraw("\eP\e[2 q\e]12;#FF00DF\<C-g>\e\\")
     augroup end

thanks for the reply and tips, lots of useful information in there.

Lots of editors and IDEs came and went while Emacs/Vim persisted. Through my three decade career I recall the ascents and downfalls of tools like BRIEF, CodeWright, NEdit, JEdit, TextPad, Notepad++, Visual Studio, JBuilder, Eclipse, Sublime and a few others so the cemetary (or hospice in some of those cases) is large.

Sublime, nor Visual Studio are in the cemetery.

Visual Studio is very much dying. Visual Studio Code is its successor that's very much alive. Those are two different products

I'm sticking with emacs for now because it is the only editor I have encountered that actually works well in conjunction with a tiling window manager; by which I mean: it works well as a single process accessed through multiple windows (here I mean "windows" as in OS windows -- internally Emacs calls this "frames") although it has features for managing panes internally, it doesn't insist that you use them and each windows is very lightweight (no thick sidebars, embedded terminal, etc that are hard or impossible to remove). Vim offers the second feature but not the first (each window is a separate process), most other editors I've encountered do not offer the second feature.

Kakoune does this too, and it’s amazing with a tiling window manager. On a big monitor, I can get 4-5 terminal emulators across, and in any of them, at any time, I can attach a kakoune client, copy and paste between buffers in different windows, edit the same file in two places at the same time, close all the clients and reattach later, and so on. Emacs is the only other editor that does this, as far as I know.

Thanks, I might give that a try :)

To put it into perspective: vi was already 15 years old when Bram decided to write vim for the Amiga, which had a GUI - so vim already looked out of place on the Amiga too! - but it was still successful, of course (I think) mostly because of being ported to Linux pretty much at the same time as Linux got started.

Amiga by default had an Emacs clone on every install.

That's incredible. Why? And why a clone? ???

Probably because GNU Emacs was too bloated for the Amiga's 512KB of RAM (or whatever amount the original model had).

They also might have been conserving storage space. Though Emacs did run on other contemporary systems.

To me, vscode is unbearably slow. I think that alone is enough to keep vim alive.

Also, I don't really miss anything from more advanced ides when in vim. There are great packages for almost anything.

I use VIM bindings in VS Code. Always assumed many do but might be wrong

Ditto.

I went from vim to neovim, but the LSPs for python/go(lang) for large files (not that large, maybe 10k loc) seem to really bog it down (back then, no idea if it's better now), whereas with VS Code it was still performant enough. So I ended up using VS Code with Vim bindings.

And yes, with ad hoc work, I still end up using system vim when just doing simple edits (e.g. adding a line to README.md or somesuch)

At work I often switched to VSCode because I couldn't get pyright to work with our django project. The errors everywhere were just annoying to look at. So I looked around and found "ruff" and "jedi_language_server". This combination seems to do the trick. I don't have to configure anything. I source my venv and it "just works". I assume our python codebase is something around the 10k LOC, too. I am not mainly responsible for the python part, so I don't spent excessive amount of time in there, but for the time I do, it works nicely

- https://github.com/pappasam/jedi-language-server

- https://github.com/astral-sh/ruff

Similar. I use IntelliJ, Neovim, and some Zed all with vim keybindings. Modal editing just fits my mind. As an aside it’s also one of the reasons I dislike Notion. I feel like I’m always inadvertently changing the content.

Me too (there doesn't seem to be plugin that's completely free of issues unfortunately). Vi/Vim is basically the universal text input model which allows me to transcend text editors and platforms. Also I quite often find myself starting a vim instance inside the VSCode terminal for quick text edits.

I use the "VSCode Neovim" extension which lets me use a real Neovim instance inside VS Code, including my personalized vimrc and a lot of plugins. Not all plugins work but if they're just textual good chance they do.

Do the Vim bindings work in VSCodium as well?

This google trends graph is very illustrative: https://trends.google.com/trends/explore?date=all&q=emacs,vi...

emacs is surely on a decline, but it’s not obvious that Vim is on the same trend.

This matches “theory” and anecdotal evidence: the people who chose emacs probably didn’t like modal editing, and when “better” IDEs came along they just switched. But there’s nothing like Vim (except editors specifically inspired by Vim), and those haven’t gotten any traction if only because every one of us Vim users have hjkl muscle memory burned into our brains.

Google translate says vim = 'I came' in portuguese, so I guess that explains Brazil.

google trends can disambiguate the context

https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...

both decline, but emacs is steeper

I've never been able to use vim productively, at best I use it to write commits, do interactive rebases and some remote server configuration (cheap VPS for a website); I never really "grew up" with it and stuck with Notepad++ and Eclipse when I started out in software development nearly 20 years ago.

I will concede that VS Code is the default for many, but I just can't get productive in it anymore. I mainly use intellij, which has its own issues. But I can't say I've ever mastered any editor, the closest was sublime text, and that mastery mainly came from being able to use cmd+p and global search effectively.

You probably have a good reason for not doing it, but mastering your editor is a great power up. Especially when the task can be ruled based and repetitive. Like a loop of find-select-transform action.

Vim may die, but vim-mode will definitely be around.

Speaking for myself, I only used Neovim because of its modularity and the keybindings. Imho, everyone should give the basic Vim keybindings a chance at least once and see if they like it.

At this point, however, I do not really use Neovim anymore. I switched to Zed, the Vim emulation is pretty good and customizable and most functionality I want is already there along with incoming support for Jupyter Notebooks. VSCode also has these features.

It is fun to use Vim/Neovim but unless I need to use it, I doubt I will return to it.

Some time in the 80s (or maybe even 90s?) Bill Joy said he just uses ed, even though he's the original author of vi. That worked for him. I believe Linus still uses that 1980s Emacs-y clone that he kind of maintains for himself. jwz uses some flavour of Lucid Emacs/XEmacs from who-knows-when instead of "standard" GNU Emacs.

In the end, it doesn't really matter what other people are using. If Vim (or Emacs) works for you, then you can basically keep using it until the end of time since code are just text files, and these things don't really change all that much (outside of encodings, which is the biggest problem with older editors – but I don't see UTF-8 replaced any time soon, if ever).

I don't really know what the kids these days are up to, but I don't think it really matters. I guess there's still few Bill Joys around using ed, but the existence of vi, Vim, VSCode, or anything else doesn't really take away anything for them.

Emacs and Vim have remained popular through several generations. What do developer surveys say? Vim was near the top a few years ago, iirc.

With nvim, there has been quite the resurgence of Vim. Good software tends to be resilient. I believe both emacs and vim will see many, many more years.

Neovim feels indeed the proper future-proof evolution of a standard. Its still a bit cumbersome to setup (fonts, lots of plugins to configure, opinionated and overly decorated UI etc.). The acid test of maturity is the dry functionality you get out of the box in a fresh linux. It should be "just right", introducing the new thinking and functionality of neovim without getting in the way.

I actually like `nvim --clean`, which is just the basics. Early on in the Neovim project, a lot of heirloom defaults were changed to be more modern, resulting in a better (IMHO) out-of-the-box experience. I use `nvim --clean` as my man-page viewer:

  MANPAGER=nvim --clean -c "colo sorbet" +Man!

Startup speed is blistering.

My current config is pretty stable, and not that large. But if it were causing issues, I'd seriously consider only doing LSP setup, which is not that onerous with the latest APIs (it was already fairly easy with `vim.lsp.start`, but `vim.lsp.config` and `vim.lsp.enable` make it easier still: https://neovim.io/doc/user/lsp.html).

I wonder, will there be something to emacs, as nvim is to vim?

Emacs seems to be a local maximum that is difficult to overcome. An entire Lisp Machine environment would be better, but it would be a tremendous undertaking and the specialists, i.e. emacs devs, don't seem to be interested in such a thing.

A multithreaded version of emacs would also be an interesting addition; I read some arguments against moving emacs to a multithreaded model, but I don't really remember them.

> I read some arguments against moving emacs to a multithreaded model, but I don't really remember them.

Everyone including the maintainers would like this to happen. The arguments against it are technical hurdles. Emacs is a large ball of global state and the lisp evaluator hooks into everything, including the display engine, so it's not clear to anyone how to disentangle things to the point where the interpreter lock can be released.

There’s (arguably) an argument to be made that Emacs configuration distributions fit that niche - Doom Emacs, Spacemacs, and Prelude provide varying flavours for different kinds of Emacs users.

Apart from that, I don’t really know what an application would be to Emacs as nvim is to Vim. It’s more like nvim is to Vim what Emacs is to nano, except Emacs came first.

Let's not forget that GNU Emacs also had his competitor, XEmacs which spurred GNU Emacs to improve. Similar with GCC and EGCS where the EGCS later became the new GCC.

This already happened, decades ago. Xemacs was widely deployed for a while. For that matter, vim is the most popular of several editors that did this to vi. (Elvis, stevie, nvi, others probably.) At any rate, I think Xemacs is still more or less maintained, but I haven’t seen anybody use it in decades.

sacrificing all existing elisp code makes a new editor worthless, maintaining compatibility makes it extraordinarily hard to get anywhere.

https://survey.stackoverflow.co/2024/technology#1-other-tool...

emacs is 4% vs VSCode 73%, so it's not popular, though vim still is

Thanks. In more detail:

    Visual Studio Code 73.6%
    Visual Studio 29.3%
    IntelliJ IDEA 26.8%
    Notepad++ 23.9%
    Vim 21.6%
    Android Studio 16.1%
    PyCharm 15.1%
    Jupyter Notebook/JupyterLab 12.8%
    Neovim 12.5%
    ...
    Emacs 4.2%
    ...
    Spacemacs 0.4%

So Vim + Neovim = 34.1%, essentially second to Visual Studio, the overwhelming leader.

StackOverflow isn't representative. It was always skewed towards .NET world (and thus VS). I assume this is the case because the founders were prominent .NET personalities.

There's no representative community though

What this doesn't show is people using vscode/vs with neovim driver or vim key bindings. The vim "backend" percentage is going to be significant.

I don't think you can add them, respondents could select multiple editors. I am guessing 34% is the upper limit if no Neovim users use Vim and vice versa, which is hard to believe.

This feels like it's skewed by the question: "Which development environments did you use". I know that vim is an IDE, but I still think of it as a text editor. I would probably answer "Zed" to that question (not even on the list!) and "vim" to a "Which text editor" question, although I use a third, graphical editor (CotEditor) for a lot of stuff too. I never use a full-blown 'ide' like visual studio.

I wonder why is Spacemacs listed as a separate entry?

You could probably lump PyCharm and IntelliJ together; different language modes of effectively the same editor.

I'm pleasantly surprised Notepad++ is so high up.

Isn't stackoverflow's most-accessed question to date "how do I exit vim?"

More like top-200+ by views, though even the wouldn’t contradict much else

One of the kids in my computer club found himself to be an avid Helix user. I guess once the dust settles around nvim's approach to LSP and stuff, give or take 5 years, it will build itself quite a following, including young people. I think the hackability is attractive.

I think Neovim helps with this, though last time I was using it (via... bootstrap? One of the prebuilt addon packs) at some point a Mason update broke my LSPs for multiple languages and i went back to VS Code on my Linux laptop because I didn't want to fight with it.

I ran screaming from VS when I noticed how much resources it used and what software it copies on remote servers in case you want to work remote. Did this improve at all in the last year+?

I had a easy to maintain, easy to understand vim + ALE + Gutentags + ... setup for C/C++ development and it worked very well but when I got into webdev I just gave up and jump to a neovim distribution as I was not able to catch up. So in the end neovim got me not because it is technically superior but because the community created distributions, which I am very grateful for (R.I.P Lunarvim)

EDIT: Ok, maybe the reason distributions were created is because the integration of some lsp/treesitter stuff enabled it/made it easier ? So if not technically superior, at least more capable

I assume slowly over time Neovim will just win over vim because of this. I do want to say its much more capable than the original vim, I don't know that vim has a headless mode or that it intends on it, but Neovim has that, plus it can essentially let you write plugins in any language with its plugin RPC protocol. So if you want a plugin that targets your language you can leverage existing libraries that directly support your language instead of writing it all from scratch in Vimscript.

Vim does have headless mode, iirc. I used it with eclipse or netbeans, can't exactly remember.

I have Neovim, it still haven't replaced vim yet. But I see the reasoning, IF I want to use a editor to do heavy development, Neovim seems to have more detailed syntax highlighting, and yes LSP integration good.

I use intelliJ with ideaVim for my work, and I don't think these editors can fill the capability that JetBrains offers. Even though vim has a special place in my heart

> I use intelliJ with ideaVim for my work, and I don't think these editors can fill the capability that JetBrains offers. Even though vim has a special place in my heart

I keep wanting them to make a Neovim headless plugin for their IDEs.

I loved LunarVim as well but after switching to AstroNvim I like it more. And it's easy to customize even for a very burned out dev like myself.

I also jumped ship to AstroNvim but I still prefer Lunarvim, I liked having all the config in just one file and some of its defaults. But I agree, Astro is the best distro currently maintained distro in my opinion.

You can definitely put all of your configuration into a single file for AstroNvim if you want.

In the docs it shows the minimal configuration to get AstroNvim running which is <10 lines in your ~/.config/init.lua file and then anything else you can just drop in that same file if you want. (https://github.com/AstroNvim/AstroNvim?tab=readme-ov-file#mi...)

Here is a user on GitHub that has a single file AstroNvim configuration: https://github.com/20k-ultra/dotfiles/blob/master/nvim/init....

Thanks for the Intel. I found my comment shallow but now I am happy I wrote it.

One file worked fine until it didn't. At one point it was 500+ lines and became unwieldy to manage.

Though I might one day switch to Zed or Helix -- I want an editor that has more bells and whistles built-in and that I could just switch them off if I don't want them. Which should be a much smaller configuration footprint compared to what we have today with Neovim.

Tangentially related and as an Emacs user, I still see the editor as a platform that bends to my needs https://xenodium.com/a-platform-that-moulds-to-your-needs

Previous discussion: https://news.ycombinator.com/item?id=42665222

>he started adding more potentially controversial changes, such as support for the XDG base directory specification

It feels like every single user-facing open source project needs to have its own XDG drama at some point.

I don't understand how it's a drama. It's an old spec, it's easy to follow, it's standard, and you can still keep compact with the old .dir at user root if you want.

What's the big deal ?

Some people really don’t like change. I understand that, but I think that the XDG directory spec is really worth having. It’s wonderful to unclutter $HOME.

But I do get that for those of us who’ve been using Unix for decades it can be a bit weird when stuff which used to be under $HOME/.$WHATEVER ends up under $HOME/.config/$WHATEVER.

"DNS was also troublesome—the vim.org domain was managed by Stefan Zehl"

vim.org was created (probably around 1998) and has been owned by Sven Guckes for most of its existence. In the beginning Sven also managed the content but I think at some point Bram took over. Unfortunately Sven passed away not long before Bram.

Worth noting there are still elvis and the one true vi available, in case vim gets foobar'd, though I haven't checked their respective states now and last used either over ten years ago. Like with shells, I've always wondered why people are so quick to jump onto particular implementations when the value is in the wide availability of editors implementing vi key bindings, and the comfort of building up muscle memory this brings. Obviously, I couldn't care less about "plugins".

And nvi, the 4.4BSD unencumbered reimplementation.

LSP as a replacement for original vi's cscope integration is the main reason I eventually switched from nvi to vim.

I'm glad I was introduced to NeoVim, because it led me to using Vim bindings in Zed.

As a new user to NeoVim, I was okay with investing some time, but man it feels like each update to NeoVim itself, or even the popular plugins, breaks something that I then need to go hunt down and fix. Every answer online isn't any better, pointing to 5 different doc pages. I like my IDEs to "just work" and continue to do so after I have them configured.

vim is everywhere. Vim bindings in window manager. If will last as long as we will be using keyboards.

Reply on news.ycombinator.com