Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Vim

lwn.net

Post reply on HN
Print view View original

51–60 of 203 posts

Re: The State of Vim

#51

Post by fp64 »

emblaegh wrote: post #37
openmarkand wrote: post #30

Earlier quoted context omitted.

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…

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.

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

Re: The State of Vim

#52

Post by fomine3 »

The_Colonel wrote: post #32
mmooss wrote: post #10

Earlier quoted context omitted.

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

Re: The State of Vim

#53

Post by StefanBatory »

flohofwoe wrote: post #29
eviks wrote: post #12

Earlier quoted context omitted.

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)

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

Re: The State of Vim

#54

Post by eviks »

camgunz wrote: post #45
eviks wrote: 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…

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

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 )

Re: The State of Vim

#55

Post by johnnyanmac »

flohofwoe wrote: post #29
eviks wrote: post #12

Earlier quoted context omitted.

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.

Re: The State of Vim

#56

Post by ookdatnog »

dmortin wrote: 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'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.

Re: The State of Vim

#57

Post by oneeyedpigeon »

mmooss wrote: post #10
eviks wrote: 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.

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.

Re: The State of Vim

#58

Post by cjfd »

eviks wrote: post #31
flohofwoe wrote: post #29

Earlier quoted context omitted.

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)

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…

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?

Re: The State of Vim

#59

Post by Cthulhu_ »

dmortin wrote: 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 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.

Re: The State of Vim

#60

Post by Maken »

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

Post reply on HN