9 ms·

The State of Vim

264 points by signa11 2y ago

omoikane 2y ago
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 https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
- eviks 2y ago
  that'd be the wrong lesson to extend a period of using a bad governance model for longer
  - flohofwoe 2y ago
    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)
    - eviks 2y ago
      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"
      - bawolff 2y ago
        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.
        eviks 2y ago
        Reality is not binary, so this extreme simplification is counterproductive when describing one
      - riffraff 2y ago
        > 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.
      - camgunz 2y ago
        > 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?
        eviks 2y ago
        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 )
    - psychoslave 2y ago
      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.
      - fsloth 2y ago
        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).
        Propelloni 2y ago
        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 https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
        flohofwoe 2y ago
        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.
    - StefanBatory 2y ago
      Or HN too. I think most of us would agree that dang is a very good moderator.
    - johnnyanmac 2y ago
      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.
      - normie3000 2y ago
        > potential rouge actors Communist assets?
        wakawaka28 2y ago
        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.
        ahartmetz 2y ago
        I think you missed the joke. "Rouge" is French for red. Most likely it was meant to say "rogue" but it was misspelled.
      - vlovich123 2y ago
        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.
      - w0m 2y ago
        > 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.
    - pif 2y ago
      > software projects don't need to be democracies Especially opens source ones, where anyone can spawn their own kingdom via a simple "git clone".
    - tomrod 2y ago
      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_theorem https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theore...
    - giancarlostoro 2y ago
      > 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.
    - bee_rider 2y ago
      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.
HellsMaddy 2y ago
Previous discussion: https://news.ycombinator.com/item?id=42665222 https://news.ycombinator.com/item?id=42665222
dmortin 2y ago
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.
- mmooss 2y ago
  Emacs and Vim have remained popular through several generations. What do developer surveys say? Vim was near the top a few years ago, iirc.
  - krykp 2y ago
    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.
    - openrisk 2y ago
      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.
      - aktau 2y ago
        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 https://neovim.io/doc/user/lsp.html).
deleted 2y ago
[deleted]
xenodium 2y ago
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 https://xenodium.com/a-platform-that-moulds-to-your-needs
porphyra 2y ago
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.
- mmooss 2y ago
  From the Stack Overflow survey: https://news.ycombinator.com/item?id=42811182 https://news.ycombinator.com/item?id=42811182 Vim 21.6% Neovim 12.5% I wonder what it looked like in prior years.
  - joeblubaugh 2y ago
    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.
    - wirrbel 2y 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 https://de.wikipedia.org/wiki/Der_Letzte_seines_Standes%3F
      - mmooss 2y ago
        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.
weinzierl 2y ago
"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.
dsign 2y ago
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.
Maken 2y ago
>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.
- BiteCode_dev 2y ago
  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 ?
  - eadmund 2y ago
    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.
skirge 2y ago
vim is everywhere. Vim bindings in window manager. If will last as long as we will be using keyboards.
cassepipe 2y ago
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
- giancarlostoro 2y ago
  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.
  - t_mahmood 2y ago
    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
    - giancarlostoro 2y ago
      > 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.
- 2y ago
ykonstant 2y ago
> 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.
- surajrmal 2y ago
  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.
- sodapopcan 2y ago
  > 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.
  - ykonstant 2y ago
    I agree completely.
- otikik 2y ago
  > 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.
deleted 2y ago
[deleted]
tannhaeuser 2y ago
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".
- kps 2y ago
  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.
alp1n3_eth 2y ago
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.

264 points by signa11 2y ago

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 https://en.wikipedia.org/wiki/Benevolent_dictator_for_life

eviks 2y ago
that'd be the wrong lesson to extend a period of using a bad governance model for longer
- flohofwoe 2y ago
  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)
  - eviks 2y ago
    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"
    - bawolff 2y ago
      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.
      - eviks 2y ago
        Reality is not binary, so this extreme simplification is counterproductive when describing one
    - riffraff 2y ago
      > 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.
    - camgunz 2y ago
      > 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?
      - eviks 2y ago
        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 )
  - psychoslave 2y ago
    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.
    - fsloth 2y ago
      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).
      - Propelloni 2y ago
        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 https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
        flohofwoe 2y ago
        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.
  - StefanBatory 2y ago
    Or HN too. I think most of us would agree that dang is a very good moderator.
  - johnnyanmac 2y ago
    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.
    - normie3000 2y ago
      > potential rouge actors Communist assets?
      - wakawaka28 2y ago
        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.
        ahartmetz 2y ago
        I think you missed the joke. "Rouge" is French for red. Most likely it was meant to say "rogue" but it was misspelled.
    - vlovich123 2y ago
      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.
    - w0m 2y ago
      > 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.
  - pif 2y ago
    > software projects don't need to be democracies Especially opens source ones, where anyone can spawn their own kingdom via a simple "git clone".
  - tomrod 2y ago
    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_theorem https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theore...
  - giancarlostoro 2y ago
    > 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.
  - bee_rider 2y ago
    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.

HellsMaddy 2y ago

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

dmortin 2y ago

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.

mmooss 2y ago
Emacs and Vim have remained popular through several generations. What do developer surveys say? Vim was near the top a few years ago, iirc.
- krykp 2y ago
  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.
  - openrisk 2y ago
    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.
    - aktau 2y ago
      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 https://neovim.io/doc/user/lsp.html).

deleted 2y ago

[deleted]

xenodium 2y ago

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 https://xenodium.com/a-platform-that-moulds-to-your-needs

porphyra 2y ago

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.

mmooss 2y ago
From the Stack Overflow survey: https://news.ycombinator.com/item?id=42811182 https://news.ycombinator.com/item?id=42811182 Vim 21.6% Neovim 12.5% I wonder what it looked like in prior years.
- joeblubaugh 2y ago
  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.
  - wirrbel 2y 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 https://de.wikipedia.org/wiki/Der_Letzte_seines_Standes%3F
    - mmooss 2y ago
      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.

weinzierl 2y ago

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

dsign 2y ago

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.

Maken 2y ago

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

BiteCode_dev 2y ago
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 ?
- eadmund 2y ago
  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.

skirge 2y ago

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

cassepipe 2y ago

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

giancarlostoro 2y ago
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.
- t_mahmood 2y ago
  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
  - giancarlostoro 2y ago
    > 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.
2y ago

ykonstant 2y ago

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

surajrmal 2y ago
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.
sodapopcan 2y ago
> 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.
- ykonstant 2y ago
  I agree completely.
otikik 2y ago
> 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.

deleted 2y ago

[deleted]

tannhaeuser 2y ago

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

kps 2y ago
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.

alp1n3_eth 2y ago

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.