Live data from Hacker News

The State of Vim

lwn.net

91–100 of 203 posts

Re: The State of Vim

#91
post #4

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.

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

Do the Vim bindings work in VSCodium as well?

Re: The State of Vim

#92
post #4

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.

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.

Re: The State of Vim

#93
post #31

Earlier quoted context omitted.

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…

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 hav…

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.

Re: The State of Vim

#94

Earlier quoted context omitted.

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 ac…

> 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.

Re: The State of Vim

#95
post #75

Earlier quoted context omitted.

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.

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.

Re: The State of Vim

#96

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.

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.

Re: The State of Vim

#97
post #4

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.

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

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.

Re: The State of Vim

#98
post #4

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.

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 intel…

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.

Re: The State of Vim

#99
post #33
post #4

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.

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.

Re: The State of Vim

#100
post #10
post #8

Earlier quoted context omitted.

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.

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