50 ms·

Vim 9.0

433 points by craftuser 4y ago

capableweb 4y ago
As Vim9 comes alive, and Neovim community focuses on Lua plugins instead, it seems this release is finally the update that will put a hard branch on the two communities. Up until now, most plugins (except Lua-only ones of course) have worked in both editors, but it doesn't seem like Vim9 will be supported in Neovim, so I guess what people go with now, will decide what you might stick with in the future (unless you're eager to switch development environments).
- oblio 4y ago
  Minor nitpick about terminology: it's "fork" and "hard fork".
- tomtomtom777 4y ago
  Although I am currently tip-toeing on NeoVim, I still feel this is a horrible break-up. Yes, Open Source simply allows you to branch whenever you're unhappy with the original but this comes at a cost for the community. The cost of having two diverging programs to deal with. In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own. Not bad reasons in itself, but does it weigh against the tremendous cost for the community of the split? Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice? Couldn't they not convince Bram Moolenaar of proposed changes, and if not, doesn't this have a good reason. I hate NeoVim for the reason they've split, even though I understand it might become even better than Vim in the long run. You need better reasons to fork and divide an ecosystem.
  - otikik 4y ago
    It could be also argued that if Vim wanted to keep the community together they could have just deprecated vimscript and adopted Lua. Of course I am stretching things a little, I know. I personally think Neovim's reasons for a fork are valid. They wanted some parts, not others, and they were willing to pull the work. So a fork is made. That is all ok. If my memory serves both projects have interchanged patches and improvements in both directions, so everyone has benefitted in some ways. The community (communities) will live on.
  - Tyr42 4y ago
    I mean all Bram had to do was accept the async patches instead of ignoring them. Then neovim wouldn't have got off the ground. Once they started building, they wanted to "cut the cruft" and just went from there
    - mempko 4y ago
      Ignore them? Far from it. Brahm provided a lot of feedback. The authors got lazy abd forked instead of dealing with criticism of their design.
      - weakfish 4y ago
        Forking is hardly easier
        KerrAvon 4y ago
        Easier on the ego
  - capableweb 4y ago
    > In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own. > Couldn't they not convince Bram Moolenaar of proposed changes I think (but someone correct me if I'm wrong) it started out with one of the persons who started Neovim, tried to get in a patch adding async support in Vim, but Moolenaar didn't want to merge it, for one or another reason. That cascaded to a bunch of other reasons over time, like adding Lua support and trying to rely less on Vimscript. But that's how I remember it being started at least, but I could remember it wrong.
    - aidos 4y ago
      Correct. HN threads from the time: https://news.ycombinator.com/item?id=7057051 https://news.ycombinator.com/item?id=7057051 https://news.ycombinator.com/item?id=7278214 https://news.ycombinator.com/item?id=7278214
    - dvogel 4y ago
      This has entered the popular lore but I think it is easily proved false. The thread in question: https://groups.google.com/g/vim_dev/c/-4pqDJfHCsM/m/LSFNhqs2mokJ https://groups.google.com/g/vim_dev/c/-4pqDJfHCsM/m/LSFNhqs2... My read of that thread was that the initial patch had a lot of issues. The design had some flaws. The patch lacked documentation. It was like they didn't read the contributing guide. Lots of bystanders threw a bunch of noise into an otherwise normal dev process. Bram and others had reservations. Bram made good faith efforts to help them evolve the patch through iterative feedback. There was an early hint of incompatible development styles (emphasis mine): You are correct in that we added a timer to the main loop. Looking over the code once again, I think we should have altered the calls to select/poll instead, but lets discuss the practical effect of this patch *since we can work out the details some time later.* The vim dev process does tend to be slower than a lot of other open source projects. That is frustrating for some people but the model has proved remarkably sustainable. After about 1.5 months one of the authors said: Bram, I happy to see there is still some hope for this patch getting merged. Then shortly afterward the other author gave Bram an ultimatum: Thanks for taking time to look at our patch and give feedback. Besides pausing/resuming timers, are there any other blockers for merging this patch? Matt and I really want to get it merged, but there's been a recurring pattern where we address one thing only to have another brought up. If this is the last thing, we'll gladly add it. If it's not the last thing, please give us a complete list of blockers. Then we can determine if we want to continue addressing your issues or just maintain our own fork of Vim. Considering where the patch started, iterative feedback seems appropriate. Bram replied (in part): It's better to postpone including this patch until we settle down on how it works. I have had bad experiences with including a feature before it's fully working or insufficiently tested. The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history. As someone who has engaged in the vim dev process and experienced each of the things the authors of this patch experienced, my conclusion is that they came in with fairly unreasonable expectations. They seemed to have financial interests pressuring them to cap the investment they were willing to make in the process. It's worth noting that a few years later Bram came back to the notes he made from that thread and solicited feedback (https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3FwAJ https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3...) re: how timers would be used. Without the noise and suggestions to merge-now-fix-later the process went quite smoothly and the landed on a reasonable implementation that AFAICT would have solved the original need. Far from the "apathetic" epithet spawned by that 2013 thread.
  - kzrdude 4y ago
    Neovim has already been very productive by giving Vim some good competition and in so doing having better features come out in Vim. To me it doesn't make sense to 'hate' neovim for wanting to develop features that they tried to have in Vim but couldn't due to the main developer stalling it.
    - calvinmorrison 4y ago
      To me, vim has never been emacs. I run two plugins, vdebug and MRU (most recently used list... super useful). Everything else is out of the box. I like where neovim is going, I think it's great, but vim is fine for me.
  - bobbylarrybobby 4y ago
    I think Neovim had a whole bunch of other reasons to split. I'm pretty sure that Neovim's server mode, which allows it to be used with other editor frontends, is simply not present in vim. For me this is the whole reason to use Neovim. But I think it also natively supports tree sitter and/or LSPs, which really improve the coding experience. Anyway iirc Neovim wanted these features integrated into Vim itself and only started a separate project when it became clear that that wasn't going to happen. My understanding was that at the time Bram was hostile to lots of the changes that people wanted integrated. You can read some of the discussion [here](https://news.ycombinator.com/item?id=14245705 https://news.ycombinator.com/item?id=14245705) and [here](https://news.ycombinator.com/item?id=7287668 https://news.ycombinator.com/item?id=7287668)
    - deadbunny 4y ago
      And when Bram did finally add async support rather than take the neovim work and us that he did it in a specifically non compatible way. I don't know the ins and outs but as an observer that does come across as a little petty.
      - kzrdude 4y ago
        We're used to open projects but Bram's seems to be that he wants to be in control, he's the main author. So Vim is then open source but not a completely open project.
        margarina72 4y ago
        open source mean the source is a open (and few other points described in [0]). Vim licence [1] is GPL compatible. It is fully open source. Open source does not mean the maintainer is under the obligation to add features, or integrate PRs. [0]: https://opensource.org/osd https://opensource.org/osd [1]: https://www.gnu.org/licenses/vim-license.txt https://www.gnu.org/licenses/vim-license.txt
        kelnos 4y ago
  - teilo 4y ago
    Vim was stagnant until Neovim became a threat. And it was never about Lua. It was about the need for async. Bram ignored the community, and so the community responded, and made something better.
  - akerl_ 4y ago
    Nobody needs to justify forking a project to other people.
  - fatbird 4y ago
    async and embedded terminal were the original features neovim was created to realize; later, lua as the first class plugin language came in. Underlying it all, though, was that vim has a bus factor of 1: Bram. Bram is the sole chokepoint through which all change flows, and thus holds back a lot of community dev. Neovim early on pursued a working model allowing for a larger community of interested devs to contribute, and it's paid off: the originator of neovim has moved on and a new steward has taken over smoothly, and they have around 30 core contributors. So your anger at Neovim is misplaced. They created a modern vim open to many devs, and incidentally rekindled active work on vim, which had been stagnant before. You should be thanking them, even if you don't switch. You have async and terminals in vim because of them.
    - cardanome 4y ago
      Stability, backwards compatibility and ubiquity are my reasons for using VIM so I neovim doesn't really offer much for me. Yeah, I took a bit longer for async to land in VIM proper but how is that a problem? Isn't is good that Bram put his foot down and insisted to do it right-way instead of the fast way? There is already enough "move fast and break things" software out there. I am happy for neovim and some innovations are interesting but for me the disadvantages of less stability are not worth it. I don't really see a need to increase the "bus factor". VIM is not a business, it can afford to move slowly but purposefully.
      - fatbird 4y ago
        The problem, as perceived by the neovim creators, was that vim wasn't moving at all. It wouldn't have taken a bit longer; after their experience, they felt like async just wasn't on Bram's radar, and the maintenance model of vim was hostile to not-Brams. They needed to please Bram to get their patch in, and he spent months saying "fix this. Ok, now fix this. Now fix this." You can tell from Thiago's last message that he's come to believe they'll never get their patch accepted because there'll always be one more thing to fix because Bram doesn't want their patch. Stability and backwards compatibility were built into neovim from day one. I used it from the 0.1 days, never had a crash, and all my vim plugins just worked. They put incredible effort into not breaking compatibility with existing vimscript, even as they constructed a new, modern build pipeline and development model, and refactored 30% of the code out. It wasn't until they added features of their own that full compatibility was lost because Bram wasn't interested in porting their work back to vim. This really wasn't "move fast and break things". It was "vim development is stagnant, our only choice is a fork." And now Vim and Neovim are now vastly better pieces of software than Vim 7 was. Forking Vim did wonders for Vim itself.
  - williamsmj 4y ago
    I don't know if the "split" is justified, but "Some people wanted vimscript+lua instead of vimscript" is not an accurate description of the reasons for the existence of the neovim project. The goals and non-goals are stated clearly in the project charter: https://neovim.io/charter/ https://neovim.io/charter/.
  - xvilka 4y ago
    > Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice? I think, the situations are incomparable. OpenOffice is effectively dead and should admit that, it's abandonware unlike Vim which is actively developed. Let all flowers blossom. Just remove dead ones from the garden. It's infuriating that OO insists they do something while they don't, best they can do now is to just put redirection to the LO site and move on.
    - calvinmorrison 4y ago
      lest us not forget the years of good hardwork of the openoffice patchset, i think it was called Go-OO that was basically a bunch of package maintainers trying to keep OO running. That became the eventual basis for LO.
  - stonekyx 4y ago
    The split of Vim and NeoVim was actually one of the reasons why I chose to switch to Emacs 2 years ago, after sticking with Vim for ~15 years. Vim was great but the script language had always been too hard for me. NeoVim was getting a lot of development, but it was foreseeable that Vim & NeoVim would be completely incompatible someday, and I'd feel bad leaving the original Vim community for something that might eventually replace it. At that point I figured, if I have to switch, let's try something that's more stable and less likely to fork. Then I never looked back.
- wruza 4y ago
  My opinion must be marginal, but in my view neovim community took an IDE route anyway so maybe it is a good thing if they separate, provided there is a way to switch. Because when you have a function in bigpkg.tgz, no incentive exists to dedicate a smaller package to it, and that changes the entire landscape dramatically and may create political issues in it. I actually liked simple little plugins vim had back in the day and not these coc/lsp/ycm things which compete in size with the editor itself, if not outright an order of magnitude larger. I tried to go neovim at least three times and it seems to be focusing on these big things, while e.g. having long standing issues in gui functionality on windows, namely gui mode (qt-nvim) resizes, window updates, file associations. With vim9 I’ll maybe finally learn to script it as I wish.
  - jonaustin 4y ago
    Worth noting that one of the 5 listed NeoVim Non-Goals is "Turn Vim into an IDE" https://neovim.io/charter/ https://neovim.io/charter/
    - wyclif 4y ago
      Yep, "neovim taking the IDE route" is a bad take.
      - nicce 4y ago
        What it means in this context? Creation of GUI? Vim is basically IDE at this point, if you configure it well and install plugins.
        thayne 4y ago
        Note that another non-goal is "Limit third-party applications (such as IDEs!) built with Neovim" So the idea is Neovim by itself isn't an IDE. But it does enable you to build an IDE using configuration and plugins, or even embedding it in a GUI.
      - wruza 4y ago
        That’s why I inserted “community” in the middle of that sentence. Neither of the mentioned plugins are neovim’s own, it only enabled their existence. Not sure why Bram was against “async”, but I am highly suspicious about this part.
- moelf 4y ago
  IIRC one of the main reasons to split is because Vim is a one-person effort, they don't take PR and they didn't want the drastic change, so Neovim had to be a fork because there's no way to convince Vim author to take changes
  - mempko 4y ago
    This is untrue. Tons of development is done by others.
    - moelf 4y ago
      I mean: https://github.com/vim/vim/graphs/contributors https://github.com/neovim/neovim/graphs/contributors technically yes (by others too), but relatively, it's basically a one-man project
      - johncoltrane 4y ago
        Vim has had a long life before being moved to GitHub and it still isn't developed the GitHub way anyway, so those graphs are meaningless. Here are contributor lists I've gathered a few years ago from `:help versionX.txt`: https://gist.github.com/romainl/7b17317cc26a30116e51a37590229b7d https://gist.github.com/romainl/7b17317cc26a30116e51a3759022... That's 600+ non-Bram contributors up to the fork that the Neovim team made disappear from their project when they removed the relevant files.
        OJFord 4y ago
        You mean 'the git way', all GitHub's doing is looking at commit authors (different from commit committers). A checked in file with a list of names is not the way to record that, I don't blame Neovim for removing it since that's basically useless anyway.
        johncoltrane 4y ago
        Well, the two projects don't follow the same development model so comparing (artificially capped) GitHub-centric lists is not exactly conclusive. One has to dig a little bit deeper.
- thayne 4y ago
  I want to have both Lua and Vim9. While lua is definitely a better language for a lot of things, VimL, and Vim9 are better DSLs for directly manipulating the editor. And Vim9 takes away several of the rough edges with using VimL. Not to mention that there are currently a lot of great plugins written in lua, and I anticipate there will be great plugins written using vim9.
- justaj 4y ago
  I don't understand. Can't NeoVim simply add the Vim9 interpreter and be a drop-in replacement for users that are migrating from Vim (9.0) this way?
  - besnn00 4y ago
    That would potentially make NeoVim slower, because you could have plugins that use Lua, plugins that use VimL and others that use Vim9. That means 3 runtimes which can contribute to latency.
- jonathf 4y ago
  That's not necessarily true. Core maintainer of the Neovim Tjdevries is working on a compatibility layer that would allow vim9 to not only run in Neovim, but likely faster. Source: https://github.com/tjdevries/vim9jit https://github.com/tjdevries/vim9jit
rickstanley 4y ago
Is there something equivalent for LunarVim[0] or NvChad[1], in Vim ecosystem? I want to try something different. I learn a lot hacking around these opinionated setups. [0]: https://lunarvim.org/ https://lunarvim.org/ [1]: https://nvchad.github.io/ https://nvchad.github.io/
- bern4444 4y ago
  Yes, there is spacevim: https://spacevim.org https://spacevim.org
  - cercatrova 4y ago
    For emacs with vim keybindings, there is also Spacemacs https://www.spacemacs.org/ https://www.spacemacs.org/
    - Siira 4y ago
      Doom Emacs is a better alternative IMO (having used both extensively). https://github.com/doomemacs/doomemacs https://github.com/doomemacs/doomemacs
threatofrain 4y ago
Does anyone have a good from-scratch setup guide for Neovim?
- NERD_ALERT 4y ago
  https://github.com/LunarVim/Neovim-from-scratch https://github.com/LunarVim/Neovim-from-scratch
- azemetre 4y ago
  What do you want to do? My best advice would be to search up some dot files from people you may follow on GitHub. There are all kinds of configs, but typically just fork someone’s you like then make minor tweaks. Here’s mine, I also linked the three people I copied from in my read me: https://github.com/azemetre/dotfiles https://github.com/azemetre/dotfiles
  - f1refly 4y ago
    Is that a thing anyone does? Follow people on github? I'm vaguely aware that they tried making github social media but I never heard of anyone actually using it like that.
    - azemetre 4y ago
      I don’t really follow people for the social media. If there are devs I like I get to easily see what projects they follow, fork, or contribute to. It a good way to see what’s out there IMO, project wise. I found many awesome libs and CLTs this way.
- williamsmj 4y ago
  https://github.com/nvim-lua/kickstart.nvim https://github.com/nvim-lua/kickstart.nvim
- mayama 4y ago
  You can either use lunarvim or nvchad to get started quickly. It's easier to override default bindings, plugin config etc. in nvchad. Or you can use their configuration as reference and pick and choose what you need.
undoware 4y ago
I loved vi for decades, but I don't miss it. Neovim is my current go-to but even this feels stodgy these days. Helix Editor is probably my future -- it manages to have just the right features, but with saner defaults and syntax -- but it will take a while for me to work up the nerve to let go of the investment in muscle memory.
- BaculumMeumEst 4y ago
  I don't think going all in on treesitter is very practical, considering basic python indentation has not been functional for over a year. I think Helix is a little bit too much of niche layered on niche, and Kakoune is much better all around in my experience. https://github.com/nvim-treesitter/nvim-treesitter/issues/802 https://github.com/nvim-treesitter/nvim-treesitter/issues/80...
  - undoware 4y ago
    that sounds hard but I... don't often code in python? I can see bolting a fallback regex mode for the few languages that have features which ts cannot (yet) accommodate. And 'niche layered on niche' is -- well, it leaves me wondering how much you've actually used hx. The experience is nominal, the installation is sane, and it was way faster to get to 'genuinely pleasant' than nvim ever was. As a plus, nix home-manager also handles helix config, which, as a nixos user, puts it over the top for me. (home-manager also does nvim, but this is mostly mooted by my need for an elaborate (and turing-complete) Packer configuration, which has me using a separate git repo for nvim specifically)
    - BaculumMeumEst 4y ago
      I don't often code in python either, but it's a considerable red flag that one of the largest languages in the world has been completely broken for this long. It makes me not want to invest time building muscle memory for the editor. Sometimes I need to code in python, and when I do, I don't want a lot of inconsistencies and jank. That's what I mean by niche layered on niche- the editor itself is a niche project that leverages another niche project (tree-sitter) to do indentation, and when contributions on either aren't up to par it kind of falls apart. I have used the editor a decent amount and it's quite nice when it works. I don't even mind the lack of plugin extensibility because there's not really anything I needed that wasn't built in.
hossbeast 4y ago
The headline should point at the actual release announcement on vim.org https://www.vim.org/vim90.php https://www.vim.org/vim90.php
- dang 4y ago
  Ok, changed from https://groups.google.com/g/vim_announce/c/f_-N3hYxK20 https://groups.google.com/g/vim_announce/c/f_-N3hYxK20. Thanks!
mikl 4y ago
Shame that Bram is doubling down with vim9script. This will give vimscript a Python 3 moment, splitting an already small community into even smaller pieces. I wish he’d have embraced Lua like Neovim. It has already been proven to work great (half my plugins are Lua these days, and it performs great), but alas, it was not to be.
- orev 4y ago
  I agree that making a new custom scripting language wasn’t the best move, but the release notes deal with backwards compatibility concerns (and calls out Python specifically as a lesson learned).
- layer8 4y ago
  Since Vim has been Bram’s project for decades, I have some empathy for him to want to continue doing things his way and to not compromise on that. It may have taken Neovim to convince him that certain features are important, but that doesn’t mean he has to like how those are realized in Neovim. Open source is freedom, and I believe it’s okay for him to make use of his freedom to design things in his way, even if the dichotomy with Neovim is not optimal for the community. And maybe it’s not worse than (say) having both GCC and Clang.
  - dvogel 4y ago
    I don't disagree with anything you've said but I would personally take this line of argument a step further. I think Bram learned from the neovim fork. Neovim bolstered the existing lua support by reducing the impedance mismatch between the lua language and the vim host. A lot of people enjoy writing lua more than vimscript but the value-add hasn't proved compelling enough for people who didn't mind vimscript. The official neovim repo still has twice as much vimscript code as it has lua code. Even if you claim vimscript is 2x as verbose that would still leave them on equal footing within the project that is putting lua forth as an equal competitor. My impression of vim9script is that Bram had a list of goals (clearly outlined in the docs) and saw the typescript project as a model to follow. The docs themselves mention typescript as a source of inspiration for some features. The typescript project had a similar set of goals and managed to gain massive adoption both among people who had previously disliked javascript (due to the improved semantics) and people who had previously like javascript (due to the speed improvements, transpiler ergonomics, etc).
stevenjgarner 4y ago
Vim was the 4th most loved editor in 2021 at 69.7% (5th most wanted) [1], while Neovim was the most loved at 82.4% (11th most wanted). [1] https://insights.stackoverflow.com/survey/2021#section-most-loved-dreaded-and-wanted-collaboration-tools https://insights.stackoverflow.com/survey/2021#section-most-...
- layer8 4y ago
  …by the Stackoverflow crowd.
  - californical 4y ago
    Yeah I feel like this definitely skews the results. I’m experienced enough to nearly never use StackOverflow, and also experienced enough to want to use something robust and readily available (try to find a system that doesn’t have vim), so I stick with vim and am _incredibly_ happy with it. Add in that StackOverflow is mostly a tool used by more junior web developers, and I think you’ll see that other demographics (like embedded, firmware, etc) would skew even more heavily in the direction of vim + no SO usage.
    - davidatbu 4y ago
      Thank you for explicitly stating the implications of what "...by the SO crowd" means. It wasn't obvious to me at all.
    - qalmakka 4y ago
      > try to find a system that doesn’t have vim Lots of embedded and BSD systems only have old vi, not vim, out of the box though.
    - 59nadir 4y ago
      The participants of the StackOverflow survey are likely not people who end up on StackOverflow randomly when looking for answers, but are more likely to be people who answer questions or are pulled in from other communities that link to the survey in progress (language subreddits, etc.). The actual programming community skews way more towards learners than an SO survey shows. You can see here that there are more people with 5+ years experience than less: https://survey.stackoverflow.co/2022/#section-experience-years-coding https://survey.stackoverflow.co/2022/#section-experience-yea... For what it's worth I prefer NeoVim and I've programmed since 2001, I don't think experience or anything has much to do with this preference. I also think that anyone who doesn't Google stuff (and let's be honest, you'll probably end up on a Stack Exchange sub-domain when you do) for their hobby or professional programming is likely very stagnant and probably way worse and less experienced than they ought to be, since they're probably just doing the same old stuff all the time. P.S. It's trivial to find default installations that don't have Vim, I don't get how anyone who's installed desktop or server distros at this point can not remember being surprised about the absence of Vim and having to install either it or NeoVim. I remember it being almost a regular occurrence when setting up machines.
kbumsik 4y ago
> to avoid Vim-specific constructs and get closer to commonly used programming languages, such as JavaScript, TypeScript and Java. So...they make a new language to fix that? Couldn't they just use an existing language?
- moelf 4y ago
  maybe... Lua? /s
omoikane 4y ago
Lots of comments about Vim9Script here, but honestly the most noticeable change for me is the updated color scheme. Other changes: https://vimhelp.org/version9.txt.html https://vimhelp.org/version9.txt.html
- johncoltrane 4y ago
  If you have any issue with them (well… beyond "I don't like it"), feel free to open an issue here: https://github.com/vim/colorschemes/issues https://github.com/vim/colorschemes/issues
honkycat 4y ago
vim9 script? what a waste of time. Why bother? Nim, Lua, Crystal, Racket.. I guess the point is to make the migration easier, so I get that. I've been using LunarVim/Neovim lately, and it is PHENOMENAL. Highly recommended!
noisy_boy 4y ago
My work machine is Windows and I pretty much spend most of my time on IDEs like JetBrains IDEA or VSCode (too many capabilities to search equivalents for via Vim on Cygwin). Both have plugins for Vim keybindings. So for me, Vim is always present through the spirit of its keybindings which have become second nature.
iso1631 4y ago
Vim 8 changed a lot of defaults - it enabled things like search as you type, scrolling as the cursor moves down the page rather than at the last line, etc. A vimrc could revert this to standard behaviour, but that means having to have a vimrc file. I was disappointed in those decisions.
ggm 4y ago
I kinda miss Bill Joy VI and Keith Bostic NVI. In saying that, I know nvi owes Elvis more than a little. Vim is sort-of the defacto reality in my life now, but if two or three things around tab expansion and tab-to-space got fixed, I'd stick to nvi compiled and installed from pkg/ports/homebrew over anything else.
t6jvcereio 4y ago
After neovim, what's the case for using vim?
- capableweb 4y ago
  Stability. I was a long-term vim user before moving to neovim, and during my time using vim, I could count backwards-incompatible changes on one hand. Plugins rarely broke because of the editor as well. While neovim is a fast moving target (they haven't released a 1.0 version yet), sometimes the editor breaks the plugin API so you'd need to wait to upgrade until your plugins are ready for it.
gigatexal 4y ago
Cool. I mean congrats. But hasn’t all the development and such moved to neovim? I find Lua a much better and intuitive than vimscript.
arunc 4y ago
Long time user of vim as IDE, for over 20 years. I recently migrated to VS Code and I'm feeling satisfied and even more productive. I still use vim from time to time on terminals, but I don't miss it at all as an IDE.
- geoffbp 4y ago
  Use vim inside vs code right?
- davidatbu 4y ago
  I would be very interested in a write up of why you prefer VSCode, if you can spare the time!
  - dromtrund 4y ago
    I'm someone else, but I did the same thing 5 years ago. For me, the most productive environment for writing and reading code is an editor with rich language support. Text editing ergonomics and startup time are completely trivial aspects of the user experience compared to proper language support. Although vim is improving, its plugin system, configuration mechanisms and plugin ecosystem is an afterthought and requires way more fidgeting, setup and hacking to just barely be useful. When I made the switch, Bram was still vocal about how he regarded the sort of language support plugins I wanted as undesirable or irrelevant, and made no effort to accommodate things like LSP. This has changed, but at this point, it's too late. VS Code supports all the languages I need through a set of plugins it wouldn't even be possible to implement for vim, with no fidgeting required. Although I still love vim's text editing capabilities, they're not nearly enough to tip the scales. I still use vim for quick text file stuff, and even write commit messages in vim in VS Code's terminal. For actual development though, it'll never be as powerful and low maintenance as VS Code.
    - davidatbu 4y ago
      Thanks for the writeup! Others, please feel free to keep them coming!
  - 4y ago
pantulis 4y ago
Being an Emacs diehard myself, I very much enjoy when that other text editor sees a new major release. Go Vim!
gorgoiler 4y ago
What are some of the advantages of Vim’s domain specific scripting language over, say, providing a Python API?
- deleted 4y ago
  [deleted]
- yrro 4y ago
  Vim does provide a Python API :) But most Vim addons seem to be written in Vimscript, and porting them to another language (which?) is a lot of work for little practical gain (for many/most addons).
  - usrbinbash 4y ago
    And a Perl API :-)
    - yrro 4y ago
      Indeed, and Ruby, and who knows what else... surprised nodejs hasn't been shoved in as well. :) To be honest I don't know how Brad keeps up with it all. And even has enough left over to add a new bespoke scripting language with Vim 9...
      - usrbinbash 4y ago
        > and who knows what else Okay, I did a quick grep through the documentation of my distros current vim installation and came up with support for Lua, MzScheme, Perl, Python, Ruby and tcl. So yeah, there are lots of interfaces to chose from.
fithisux 4y ago
I never understood why use custom scripting and not one from the many already existing implementations.
- svlasov 4y ago
  Vim script has a long history and initially it emerged from vi commands. It is intended to talk to Vim internals, so any other language will always look and feel alien in this regard. I hope Vim script will continue evolving, albeit breaking backward compatibility.
Yuioup 4y ago
Previous discussion: https://news.ycombinator.com/item?id=31907883 https://news.ycombinator.com/item?id=31907883
the_duke 4y ago
I'm curious how many users are now using vim versus neovim. I switched a few years ago,and ever since Lua plugin support the Neovim ecosystem is thriving.
- agotterer 4y ago
  I switched to NeoVim and then back to Vim a few years ago. I ran into some bug that prevented my setup from working correctly that forced me back. Vim has been working fine for me and I haven’t found the motivation or a reason to try and switch again.
  - aidos 4y ago
    It was only in the last year or so that neovim really hit its stride. Features like treesitter provide the basis for some really interesting functionally.
- cge 4y ago
  Neovim occasionally has really basic functionality regressions compared to vim: I switched back to preferring vim after realizing that neovim silently deletes all ACLs on a file (https://github.com/neovim/neovim/issues/1200 https://github.com/neovim/neovim/issues/1200). However, I use Emacs and VS Code for more involved editing, and mostly use vim as a light remote editor via SSH, so my priorities may be very different.
- nobleach 4y ago
  I stuck with Vim for a long time. I had friends that made the jump and honestly, around version 0.4.3, it still didn't seem to offer anything I cared about. So I stuck with my decade old .vimrc. I had started to get into CoC stuff, and NeoVim was just starting to release their native LSP integration. On a whim, I decided to give it a shot. I ended up sticking with it. Now there'd have to be a heck of a good reason for me to go back. I never enjoyed VimL. Any of the personal plugins I've written, I've had to struggle through writing. While Lua isn't the most amazing language either, I do like it far more. I feel like NeoVim's ecosystem is pushing the boundaries far more than Vim but, isn't that kinda what Vim wanted? They want to remain the conservative slow-moving text-editor. There's nothing wrong with that at all!
givemeethekeys 4y ago
I'm curious: - How deep a rabbit hole do most people go down when setting up their vim / neovim environment? Apart from setting up a preferred color and language specific tab spacing and highlighting, I don't need more, but I've seen some pretty fancy setups. Out of the different plugins, which would you never operate without?
- cercatrova 4y ago
  Out of everything, if I want to use (neo)vim as a serious code editing environment, it has got to be LSP support. To that end, I use coc.vim although of course there are many other LSP plugins.
- jl6 4y ago
  I put some time into learning vanilla vim to a fairly basic level, about 20 years ago. It’s been sufficient ever since. Occasionally I look up rarely used commands, but as far as I’m concerned my configuring days are over.
- VTimofeenko 4y ago
  I've gone down that rabbit hole quite a few times and each time for a much longer period than I am willing to admit. I use neovim for hobby development and as a general text editor. The plugin that I find myself using all the time is vim-surround with a couple of minor language-specific tweaks.
- deleted 4y ago
  [deleted]
- dbrueck 4y ago
  No idea if I'm typical or an outlier, but I have a couple of syntax highlighting plugins, NLKNguyen/papercolor-theme, a vim rc file with my favorite keybindings (e.g. faster navigation among splits), and a python file with some helpers for opening terminals in vim and... that's it. Every once in awhile I think I might do a fancier setup but then I lose interest. Ditto for checking out neovim. I'm sure I'd get some gains, but I guess I've sort of settled into a decent sweet spot that I haven't left for almost a decade, haha (been using vim for ~25 years total).
deleted 4y ago
[deleted]

433 points by craftuser 4y ago

As Vim9 comes alive, and Neovim community focuses on Lua plugins instead, it seems this release is finally the update that will put a hard branch on the two communities. Up until now, most plugins (except Lua-only ones of course) have worked in both editors, but it doesn't seem like Vim9 will be supported in Neovim, so I guess what people go with now, will decide what you might stick with in the future (unless you're eager to switch development environments).

oblio 4y ago
Minor nitpick about terminology: it's "fork" and "hard fork".
tomtomtom777 4y ago
Although I am currently tip-toeing on NeoVim, I still feel this is a horrible break-up. Yes, Open Source simply allows you to branch whenever you're unhappy with the original but this comes at a cost for the community. The cost of having two diverging programs to deal with. In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own. Not bad reasons in itself, but does it weigh against the tremendous cost for the community of the split? Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice? Couldn't they not convince Bram Moolenaar of proposed changes, and if not, doesn't this have a good reason. I hate NeoVim for the reason they've split, even though I understand it might become even better than Vim in the long run. You need better reasons to fork and divide an ecosystem.
- otikik 4y ago
  It could be also argued that if Vim wanted to keep the community together they could have just deprecated vimscript and adopted Lua. Of course I am stretching things a little, I know. I personally think Neovim's reasons for a fork are valid. They wanted some parts, not others, and they were willing to pull the work. So a fork is made. That is all ok. If my memory serves both projects have interchanged patches and improvements in both directions, so everyone has benefitted in some ways. The community (communities) will live on.
- Tyr42 4y ago
  I mean all Bram had to do was accept the async patches instead of ignoring them. Then neovim wouldn't have got off the ground. Once they started building, they wanted to "cut the cruft" and just went from there
  - mempko 4y ago
    Ignore them? Far from it. Brahm provided a lot of feedback. The authors got lazy abd forked instead of dealing with criticism of their design.
    - weakfish 4y ago
      Forking is hardly easier
      - KerrAvon 4y ago
        Easier on the ego
- capableweb 4y ago
  > In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own. > Couldn't they not convince Bram Moolenaar of proposed changes I think (but someone correct me if I'm wrong) it started out with one of the persons who started Neovim, tried to get in a patch adding async support in Vim, but Moolenaar didn't want to merge it, for one or another reason. That cascaded to a bunch of other reasons over time, like adding Lua support and trying to rely less on Vimscript. But that's how I remember it being started at least, but I could remember it wrong.
  - aidos 4y ago
    Correct. HN threads from the time: https://news.ycombinator.com/item?id=7057051 https://news.ycombinator.com/item?id=7057051 https://news.ycombinator.com/item?id=7278214 https://news.ycombinator.com/item?id=7278214
  - dvogel 4y ago
    This has entered the popular lore but I think it is easily proved false. The thread in question: https://groups.google.com/g/vim_dev/c/-4pqDJfHCsM/m/LSFNhqs2mokJ https://groups.google.com/g/vim_dev/c/-4pqDJfHCsM/m/LSFNhqs2... My read of that thread was that the initial patch had a lot of issues. The design had some flaws. The patch lacked documentation. It was like they didn't read the contributing guide. Lots of bystanders threw a bunch of noise into an otherwise normal dev process. Bram and others had reservations. Bram made good faith efforts to help them evolve the patch through iterative feedback. There was an early hint of incompatible development styles (emphasis mine): You are correct in that we added a timer to the main loop. Looking over the code once again, I think we should have altered the calls to select/poll instead, but lets discuss the practical effect of this patch *since we can work out the details some time later.* The vim dev process does tend to be slower than a lot of other open source projects. That is frustrating for some people but the model has proved remarkably sustainable. After about 1.5 months one of the authors said: Bram, I happy to see there is still some hope for this patch getting merged. Then shortly afterward the other author gave Bram an ultimatum: Thanks for taking time to look at our patch and give feedback. Besides pausing/resuming timers, are there any other blockers for merging this patch? Matt and I really want to get it merged, but there's been a recurring pattern where we address one thing only to have another brought up. If this is the last thing, we'll gladly add it. If it's not the last thing, please give us a complete list of blockers. Then we can determine if we want to continue addressing your issues or just maintain our own fork of Vim. Considering where the patch started, iterative feedback seems appropriate. Bram replied (in part): It's better to postpone including this patch until we settle down on how it works. I have had bad experiences with including a feature before it's fully working or insufficiently tested. The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history. As someone who has engaged in the vim dev process and experienced each of the things the authors of this patch experienced, my conclusion is that they came in with fairly unreasonable expectations. They seemed to have financial interests pressuring them to cap the investment they were willing to make in the process. It's worth noting that a few years later Bram came back to the notes he made from that thread and solicited feedback (https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3FwAJ https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3...) re: how timers would be used. Without the noise and suggestions to merge-now-fix-later the process went quite smoothly and the landed on a reasonable implementation that AFAICT would have solved the original need. Far from the "apathetic" epithet spawned by that 2013 thread.
- kzrdude 4y ago
  Neovim has already been very productive by giving Vim some good competition and in so doing having better features come out in Vim. To me it doesn't make sense to 'hate' neovim for wanting to develop features that they tried to have in Vim but couldn't due to the main developer stalling it.
  - calvinmorrison 4y ago
    To me, vim has never been emacs. I run two plugins, vdebug and MRU (most recently used list... super useful). Everything else is out of the box. I like where neovim is going, I think it's great, but vim is fine for me.
- bobbylarrybobby 4y ago
  I think Neovim had a whole bunch of other reasons to split. I'm pretty sure that Neovim's server mode, which allows it to be used with other editor frontends, is simply not present in vim. For me this is the whole reason to use Neovim. But I think it also natively supports tree sitter and/or LSPs, which really improve the coding experience. Anyway iirc Neovim wanted these features integrated into Vim itself and only started a separate project when it became clear that that wasn't going to happen. My understanding was that at the time Bram was hostile to lots of the changes that people wanted integrated. You can read some of the discussion [here](https://news.ycombinator.com/item?id=14245705 https://news.ycombinator.com/item?id=14245705) and [here](https://news.ycombinator.com/item?id=7287668 https://news.ycombinator.com/item?id=7287668)
  - deadbunny 4y ago
    And when Bram did finally add async support rather than take the neovim work and us that he did it in a specifically non compatible way. I don't know the ins and outs but as an observer that does come across as a little petty.
    - kzrdude 4y ago
      We're used to open projects but Bram's seems to be that he wants to be in control, he's the main author. So Vim is then open source but not a completely open project.
      - margarina72 4y ago
        open source mean the source is a open (and few other points described in [0]). Vim licence [1] is GPL compatible. It is fully open source. Open source does not mean the maintainer is under the obligation to add features, or integrate PRs. [0]: https://opensource.org/osd https://opensource.org/osd [1]: https://www.gnu.org/licenses/vim-license.txt https://www.gnu.org/licenses/vim-license.txt
        kelnos 4y ago
- teilo 4y ago
  Vim was stagnant until Neovim became a threat. And it was never about Lua. It was about the need for async. Bram ignored the community, and so the community responded, and made something better.
- akerl_ 4y ago
  Nobody needs to justify forking a project to other people.
- fatbird 4y ago
  async and embedded terminal were the original features neovim was created to realize; later, lua as the first class plugin language came in. Underlying it all, though, was that vim has a bus factor of 1: Bram. Bram is the sole chokepoint through which all change flows, and thus holds back a lot of community dev. Neovim early on pursued a working model allowing for a larger community of interested devs to contribute, and it's paid off: the originator of neovim has moved on and a new steward has taken over smoothly, and they have around 30 core contributors. So your anger at Neovim is misplaced. They created a modern vim open to many devs, and incidentally rekindled active work on vim, which had been stagnant before. You should be thanking them, even if you don't switch. You have async and terminals in vim because of them.
  - cardanome 4y ago
    Stability, backwards compatibility and ubiquity are my reasons for using VIM so I neovim doesn't really offer much for me. Yeah, I took a bit longer for async to land in VIM proper but how is that a problem? Isn't is good that Bram put his foot down and insisted to do it right-way instead of the fast way? There is already enough "move fast and break things" software out there. I am happy for neovim and some innovations are interesting but for me the disadvantages of less stability are not worth it. I don't really see a need to increase the "bus factor". VIM is not a business, it can afford to move slowly but purposefully.
    - fatbird 4y ago
      The problem, as perceived by the neovim creators, was that vim wasn't moving at all. It wouldn't have taken a bit longer; after their experience, they felt like async just wasn't on Bram's radar, and the maintenance model of vim was hostile to not-Brams. They needed to please Bram to get their patch in, and he spent months saying "fix this. Ok, now fix this. Now fix this." You can tell from Thiago's last message that he's come to believe they'll never get their patch accepted because there'll always be one more thing to fix because Bram doesn't want their patch. Stability and backwards compatibility were built into neovim from day one. I used it from the 0.1 days, never had a crash, and all my vim plugins just worked. They put incredible effort into not breaking compatibility with existing vimscript, even as they constructed a new, modern build pipeline and development model, and refactored 30% of the code out. It wasn't until they added features of their own that full compatibility was lost because Bram wasn't interested in porting their work back to vim. This really wasn't "move fast and break things". It was "vim development is stagnant, our only choice is a fork." And now Vim and Neovim are now vastly better pieces of software than Vim 7 was. Forking Vim did wonders for Vim itself.
- williamsmj 4y ago
  I don't know if the "split" is justified, but "Some people wanted vimscript+lua instead of vimscript" is not an accurate description of the reasons for the existence of the neovim project. The goals and non-goals are stated clearly in the project charter: https://neovim.io/charter/ https://neovim.io/charter/.
- xvilka 4y ago
  > Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice? I think, the situations are incomparable. OpenOffice is effectively dead and should admit that, it's abandonware unlike Vim which is actively developed. Let all flowers blossom. Just remove dead ones from the garden. It's infuriating that OO insists they do something while they don't, best they can do now is to just put redirection to the LO site and move on.
  - calvinmorrison 4y ago
    lest us not forget the years of good hardwork of the openoffice patchset, i think it was called Go-OO that was basically a bunch of package maintainers trying to keep OO running. That became the eventual basis for LO.
- stonekyx 4y ago
  The split of Vim and NeoVim was actually one of the reasons why I chose to switch to Emacs 2 years ago, after sticking with Vim for ~15 years. Vim was great but the script language had always been too hard for me. NeoVim was getting a lot of development, but it was foreseeable that Vim & NeoVim would be completely incompatible someday, and I'd feel bad leaving the original Vim community for something that might eventually replace it. At that point I figured, if I have to switch, let's try something that's more stable and less likely to fork. Then I never looked back.
wruza 4y ago
My opinion must be marginal, but in my view neovim community took an IDE route anyway so maybe it is a good thing if they separate, provided there is a way to switch. Because when you have a function in bigpkg.tgz, no incentive exists to dedicate a smaller package to it, and that changes the entire landscape dramatically and may create political issues in it. I actually liked simple little plugins vim had back in the day and not these coc/lsp/ycm things which compete in size with the editor itself, if not outright an order of magnitude larger. I tried to go neovim at least three times and it seems to be focusing on these big things, while e.g. having long standing issues in gui functionality on windows, namely gui mode (qt-nvim) resizes, window updates, file associations. With vim9 I’ll maybe finally learn to script it as I wish.
- jonaustin 4y ago
  Worth noting that one of the 5 listed NeoVim Non-Goals is "Turn Vim into an IDE" https://neovim.io/charter/ https://neovim.io/charter/
  - wyclif 4y ago
    Yep, "neovim taking the IDE route" is a bad take.
    - nicce 4y ago
      What it means in this context? Creation of GUI? Vim is basically IDE at this point, if you configure it well and install plugins.
      - thayne 4y ago
        Note that another non-goal is "Limit third-party applications (such as IDEs!) built with Neovim" So the idea is Neovim by itself isn't an IDE. But it does enable you to build an IDE using configuration and plugins, or even embedding it in a GUI.
    - wruza 4y ago
      That’s why I inserted “community” in the middle of that sentence. Neither of the mentioned plugins are neovim’s own, it only enabled their existence. Not sure why Bram was against “async”, but I am highly suspicious about this part.
moelf 4y ago
IIRC one of the main reasons to split is because Vim is a one-person effort, they don't take PR and they didn't want the drastic change, so Neovim had to be a fork because there's no way to convince Vim author to take changes
- mempko 4y ago
  This is untrue. Tons of development is done by others.
  - moelf 4y ago
    I mean: https://github.com/vim/vim/graphs/contributors https://github.com/neovim/neovim/graphs/contributors technically yes (by others too), but relatively, it's basically a one-man project
    - johncoltrane 4y ago
      Vim has had a long life before being moved to GitHub and it still isn't developed the GitHub way anyway, so those graphs are meaningless. Here are contributor lists I've gathered a few years ago from `:help versionX.txt`: https://gist.github.com/romainl/7b17317cc26a30116e51a37590229b7d https://gist.github.com/romainl/7b17317cc26a30116e51a3759022... That's 600+ non-Bram contributors up to the fork that the Neovim team made disappear from their project when they removed the relevant files.
      - OJFord 4y ago
        You mean 'the git way', all GitHub's doing is looking at commit authors (different from commit committers). A checked in file with a list of names is not the way to record that, I don't blame Neovim for removing it since that's basically useless anyway.
        johncoltrane 4y ago
        Well, the two projects don't follow the same development model so comparing (artificially capped) GitHub-centric lists is not exactly conclusive. One has to dig a little bit deeper.
thayne 4y ago
I want to have both Lua and Vim9. While lua is definitely a better language for a lot of things, VimL, and Vim9 are better DSLs for directly manipulating the editor. And Vim9 takes away several of the rough edges with using VimL. Not to mention that there are currently a lot of great plugins written in lua, and I anticipate there will be great plugins written using vim9.
justaj 4y ago
I don't understand. Can't NeoVim simply add the Vim9 interpreter and be a drop-in replacement for users that are migrating from Vim (9.0) this way?
- besnn00 4y ago
  That would potentially make NeoVim slower, because you could have plugins that use Lua, plugins that use VimL and others that use Vim9. That means 3 runtimes which can contribute to latency.
jonathf 4y ago
That's not necessarily true. Core maintainer of the Neovim Tjdevries is working on a compatibility layer that would allow vim9 to not only run in Neovim, but likely faster. Source: https://github.com/tjdevries/vim9jit https://github.com/tjdevries/vim9jit

rickstanley 4y ago

Is there something equivalent for LunarVim[0] or NvChad[1], in Vim ecosystem? I want to try something different. I learn a lot hacking around these opinionated setups. [0]: https://lunarvim.org/ https://lunarvim.org/ [1]: https://nvchad.github.io/ https://nvchad.github.io/

bern4444 4y ago
Yes, there is spacevim: https://spacevim.org https://spacevim.org
- cercatrova 4y ago
  For emacs with vim keybindings, there is also Spacemacs https://www.spacemacs.org/ https://www.spacemacs.org/
  - Siira 4y ago
    Doom Emacs is a better alternative IMO (having used both extensively). https://github.com/doomemacs/doomemacs https://github.com/doomemacs/doomemacs

threatofrain 4y ago

Does anyone have a good from-scratch setup guide for Neovim?

NERD_ALERT 4y ago
https://github.com/LunarVim/Neovim-from-scratch https://github.com/LunarVim/Neovim-from-scratch
azemetre 4y ago
What do you want to do? My best advice would be to search up some dot files from people you may follow on GitHub. There are all kinds of configs, but typically just fork someone’s you like then make minor tweaks. Here’s mine, I also linked the three people I copied from in my read me: https://github.com/azemetre/dotfiles https://github.com/azemetre/dotfiles
- f1refly 4y ago
  Is that a thing anyone does? Follow people on github? I'm vaguely aware that they tried making github social media but I never heard of anyone actually using it like that.
  - azemetre 4y ago
    I don’t really follow people for the social media. If there are devs I like I get to easily see what projects they follow, fork, or contribute to. It a good way to see what’s out there IMO, project wise. I found many awesome libs and CLTs this way.
williamsmj 4y ago
https://github.com/nvim-lua/kickstart.nvim https://github.com/nvim-lua/kickstart.nvim
mayama 4y ago
You can either use lunarvim or nvchad to get started quickly. It's easier to override default bindings, plugin config etc. in nvchad. Or you can use their configuration as reference and pick and choose what you need.

undoware 4y ago

I loved vi for decades, but I don't miss it. Neovim is my current go-to but even this feels stodgy these days. Helix Editor is probably my future -- it manages to have just the right features, but with saner defaults and syntax -- but it will take a while for me to work up the nerve to let go of the investment in muscle memory.

BaculumMeumEst 4y ago
I don't think going all in on treesitter is very practical, considering basic python indentation has not been functional for over a year. I think Helix is a little bit too much of niche layered on niche, and Kakoune is much better all around in my experience. https://github.com/nvim-treesitter/nvim-treesitter/issues/802 https://github.com/nvim-treesitter/nvim-treesitter/issues/80...
- undoware 4y ago
  that sounds hard but I... don't often code in python? I can see bolting a fallback regex mode for the few languages that have features which ts cannot (yet) accommodate. And 'niche layered on niche' is -- well, it leaves me wondering how much you've actually used hx. The experience is nominal, the installation is sane, and it was way faster to get to 'genuinely pleasant' than nvim ever was. As a plus, nix home-manager also handles helix config, which, as a nixos user, puts it over the top for me. (home-manager also does nvim, but this is mostly mooted by my need for an elaborate (and turing-complete) Packer configuration, which has me using a separate git repo for nvim specifically)
  - BaculumMeumEst 4y ago
    I don't often code in python either, but it's a considerable red flag that one of the largest languages in the world has been completely broken for this long. It makes me not want to invest time building muscle memory for the editor. Sometimes I need to code in python, and when I do, I don't want a lot of inconsistencies and jank. That's what I mean by niche layered on niche- the editor itself is a niche project that leverages another niche project (tree-sitter) to do indentation, and when contributions on either aren't up to par it kind of falls apart. I have used the editor a decent amount and it's quite nice when it works. I don't even mind the lack of plugin extensibility because there's not really anything I needed that wasn't built in.

hossbeast 4y ago

The headline should point at the actual release announcement on vim.org https://www.vim.org/vim90.php https://www.vim.org/vim90.php

dang 4y ago
Ok, changed from https://groups.google.com/g/vim_announce/c/f_-N3hYxK20 https://groups.google.com/g/vim_announce/c/f_-N3hYxK20. Thanks!

mikl 4y ago

Shame that Bram is doubling down with vim9script. This will give vimscript a Python 3 moment, splitting an already small community into even smaller pieces. I wish he’d have embraced Lua like Neovim. It has already been proven to work great (half my plugins are Lua these days, and it performs great), but alas, it was not to be.

orev 4y ago
I agree that making a new custom scripting language wasn’t the best move, but the release notes deal with backwards compatibility concerns (and calls out Python specifically as a lesson learned).
layer8 4y ago
Since Vim has been Bram’s project for decades, I have some empathy for him to want to continue doing things his way and to not compromise on that. It may have taken Neovim to convince him that certain features are important, but that doesn’t mean he has to like how those are realized in Neovim. Open source is freedom, and I believe it’s okay for him to make use of his freedom to design things in his way, even if the dichotomy with Neovim is not optimal for the community. And maybe it’s not worse than (say) having both GCC and Clang.
- dvogel 4y ago
  I don't disagree with anything you've said but I would personally take this line of argument a step further. I think Bram learned from the neovim fork. Neovim bolstered the existing lua support by reducing the impedance mismatch between the lua language and the vim host. A lot of people enjoy writing lua more than vimscript but the value-add hasn't proved compelling enough for people who didn't mind vimscript. The official neovim repo still has twice as much vimscript code as it has lua code. Even if you claim vimscript is 2x as verbose that would still leave them on equal footing within the project that is putting lua forth as an equal competitor. My impression of vim9script is that Bram had a list of goals (clearly outlined in the docs) and saw the typescript project as a model to follow. The docs themselves mention typescript as a source of inspiration for some features. The typescript project had a similar set of goals and managed to gain massive adoption both among people who had previously disliked javascript (due to the improved semantics) and people who had previously like javascript (due to the speed improvements, transpiler ergonomics, etc).

stevenjgarner 4y ago

Vim was the 4th most loved editor in 2021 at 69.7% (5th most wanted) [1], while Neovim was the most loved at 82.4% (11th most wanted). [1] https://insights.stackoverflow.com/survey/2021#section-most-loved-dreaded-and-wanted-collaboration-tools https://insights.stackoverflow.com/survey/2021#section-most-...

layer8 4y ago
…by the Stackoverflow crowd.
- californical 4y ago
  Yeah I feel like this definitely skews the results. I’m experienced enough to nearly never use StackOverflow, and also experienced enough to want to use something robust and readily available (try to find a system that doesn’t have vim), so I stick with vim and am _incredibly_ happy with it. Add in that StackOverflow is mostly a tool used by more junior web developers, and I think you’ll see that other demographics (like embedded, firmware, etc) would skew even more heavily in the direction of vim + no SO usage.
  - davidatbu 4y ago
    Thank you for explicitly stating the implications of what "...by the SO crowd" means. It wasn't obvious to me at all.
  - qalmakka 4y ago
    > try to find a system that doesn’t have vim Lots of embedded and BSD systems only have old vi, not vim, out of the box though.
  - 59nadir 4y ago
    The participants of the StackOverflow survey are likely not people who end up on StackOverflow randomly when looking for answers, but are more likely to be people who answer questions or are pulled in from other communities that link to the survey in progress (language subreddits, etc.). The actual programming community skews way more towards learners than an SO survey shows. You can see here that there are more people with 5+ years experience than less: https://survey.stackoverflow.co/2022/#section-experience-years-coding https://survey.stackoverflow.co/2022/#section-experience-yea... For what it's worth I prefer NeoVim and I've programmed since 2001, I don't think experience or anything has much to do with this preference. I also think that anyone who doesn't Google stuff (and let's be honest, you'll probably end up on a Stack Exchange sub-domain when you do) for their hobby or professional programming is likely very stagnant and probably way worse and less experienced than they ought to be, since they're probably just doing the same old stuff all the time. P.S. It's trivial to find default installations that don't have Vim, I don't get how anyone who's installed desktop or server distros at this point can not remember being surprised about the absence of Vim and having to install either it or NeoVim. I remember it being almost a regular occurrence when setting up machines.

kbumsik 4y ago

> to avoid Vim-specific constructs and get closer to commonly used programming languages, such as JavaScript, TypeScript and Java. So...they make a new language to fix that? Couldn't they just use an existing language?

moelf 4y ago
maybe... Lua? /s

omoikane 4y ago

Lots of comments about Vim9Script here, but honestly the most noticeable change for me is the updated color scheme. Other changes: https://vimhelp.org/version9.txt.html https://vimhelp.org/version9.txt.html

johncoltrane 4y ago
If you have any issue with them (well… beyond "I don't like it"), feel free to open an issue here: https://github.com/vim/colorschemes/issues https://github.com/vim/colorschemes/issues

honkycat 4y ago

vim9 script? what a waste of time. Why bother? Nim, Lua, Crystal, Racket.. I guess the point is to make the migration easier, so I get that. I've been using LunarVim/Neovim lately, and it is PHENOMENAL. Highly recommended!

noisy_boy 4y ago

My work machine is Windows and I pretty much spend most of my time on IDEs like JetBrains IDEA or VSCode (too many capabilities to search equivalents for via Vim on Cygwin). Both have plugins for Vim keybindings. So for me, Vim is always present through the spirit of its keybindings which have become second nature.

iso1631 4y ago

Vim 8 changed a lot of defaults - it enabled things like search as you type, scrolling as the cursor moves down the page rather than at the last line, etc. A vimrc could revert this to standard behaviour, but that means having to have a vimrc file. I was disappointed in those decisions.

ggm 4y ago

I kinda miss Bill Joy VI and Keith Bostic NVI. In saying that, I know nvi owes Elvis more than a little. Vim is sort-of the defacto reality in my life now, but if two or three things around tab expansion and tab-to-space got fixed, I'd stick to nvi compiled and installed from pkg/ports/homebrew over anything else.

t6jvcereio 4y ago

After neovim, what's the case for using vim?

capableweb 4y ago
Stability. I was a long-term vim user before moving to neovim, and during my time using vim, I could count backwards-incompatible changes on one hand. Plugins rarely broke because of the editor as well. While neovim is a fast moving target (they haven't released a 1.0 version yet), sometimes the editor breaks the plugin API so you'd need to wait to upgrade until your plugins are ready for it.

gigatexal 4y ago

Cool. I mean congrats. But hasn’t all the development and such moved to neovim? I find Lua a much better and intuitive than vimscript.

arunc 4y ago

Long time user of vim as IDE, for over 20 years. I recently migrated to VS Code and I'm feeling satisfied and even more productive. I still use vim from time to time on terminals, but I don't miss it at all as an IDE.

geoffbp 4y ago
Use vim inside vs code right?
davidatbu 4y ago
I would be very interested in a write up of why you prefer VSCode, if you can spare the time!
- dromtrund 4y ago
  I'm someone else, but I did the same thing 5 years ago. For me, the most productive environment for writing and reading code is an editor with rich language support. Text editing ergonomics and startup time are completely trivial aspects of the user experience compared to proper language support. Although vim is improving, its plugin system, configuration mechanisms and plugin ecosystem is an afterthought and requires way more fidgeting, setup and hacking to just barely be useful. When I made the switch, Bram was still vocal about how he regarded the sort of language support plugins I wanted as undesirable or irrelevant, and made no effort to accommodate things like LSP. This has changed, but at this point, it's too late. VS Code supports all the languages I need through a set of plugins it wouldn't even be possible to implement for vim, with no fidgeting required. Although I still love vim's text editing capabilities, they're not nearly enough to tip the scales. I still use vim for quick text file stuff, and even write commit messages in vim in VS Code's terminal. For actual development though, it'll never be as powerful and low maintenance as VS Code.
  - davidatbu 4y ago
    Thanks for the writeup! Others, please feel free to keep them coming!
- 4y ago

pantulis 4y ago

Being an Emacs diehard myself, I very much enjoy when that other text editor sees a new major release. Go Vim!

gorgoiler 4y ago

What are some of the advantages of Vim’s domain specific scripting language over, say, providing a Python API?

deleted 4y ago
[deleted]
yrro 4y ago
Vim does provide a Python API :) But most Vim addons seem to be written in Vimscript, and porting them to another language (which?) is a lot of work for little practical gain (for many/most addons).
- usrbinbash 4y ago
  And a Perl API :-)
  - yrro 4y ago
    Indeed, and Ruby, and who knows what else... surprised nodejs hasn't been shoved in as well. :) To be honest I don't know how Brad keeps up with it all. And even has enough left over to add a new bespoke scripting language with Vim 9...
    - usrbinbash 4y ago
      > and who knows what else Okay, I did a quick grep through the documentation of my distros current vim installation and came up with support for Lua, MzScheme, Perl, Python, Ruby and tcl. So yeah, there are lots of interfaces to chose from.

fithisux 4y ago

I never understood why use custom scripting and not one from the many already existing implementations.

svlasov 4y ago
Vim script has a long history and initially it emerged from vi commands. It is intended to talk to Vim internals, so any other language will always look and feel alien in this regard. I hope Vim script will continue evolving, albeit breaking backward compatibility.

Yuioup 4y ago

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

the_duke 4y ago

I'm curious how many users are now using vim versus neovim. I switched a few years ago,and ever since Lua plugin support the Neovim ecosystem is thriving.

agotterer 4y ago
I switched to NeoVim and then back to Vim a few years ago. I ran into some bug that prevented my setup from working correctly that forced me back. Vim has been working fine for me and I haven’t found the motivation or a reason to try and switch again.
- aidos 4y ago
  It was only in the last year or so that neovim really hit its stride. Features like treesitter provide the basis for some really interesting functionally.
cge 4y ago
Neovim occasionally has really basic functionality regressions compared to vim: I switched back to preferring vim after realizing that neovim silently deletes all ACLs on a file (https://github.com/neovim/neovim/issues/1200 https://github.com/neovim/neovim/issues/1200). However, I use Emacs and VS Code for more involved editing, and mostly use vim as a light remote editor via SSH, so my priorities may be very different.
nobleach 4y ago
I stuck with Vim for a long time. I had friends that made the jump and honestly, around version 0.4.3, it still didn't seem to offer anything I cared about. So I stuck with my decade old .vimrc. I had started to get into CoC stuff, and NeoVim was just starting to release their native LSP integration. On a whim, I decided to give it a shot. I ended up sticking with it. Now there'd have to be a heck of a good reason for me to go back. I never enjoyed VimL. Any of the personal plugins I've written, I've had to struggle through writing. While Lua isn't the most amazing language either, I do like it far more. I feel like NeoVim's ecosystem is pushing the boundaries far more than Vim but, isn't that kinda what Vim wanted? They want to remain the conservative slow-moving text-editor. There's nothing wrong with that at all!

givemeethekeys 4y ago

I'm curious: - How deep a rabbit hole do most people go down when setting up their vim / neovim environment? Apart from setting up a preferred color and language specific tab spacing and highlighting, I don't need more, but I've seen some pretty fancy setups. Out of the different plugins, which would you never operate without?

cercatrova 4y ago
Out of everything, if I want to use (neo)vim as a serious code editing environment, it has got to be LSP support. To that end, I use coc.vim although of course there are many other LSP plugins.
jl6 4y ago
I put some time into learning vanilla vim to a fairly basic level, about 20 years ago. It’s been sufficient ever since. Occasionally I look up rarely used commands, but as far as I’m concerned my configuring days are over.
VTimofeenko 4y ago
I've gone down that rabbit hole quite a few times and each time for a much longer period than I am willing to admit. I use neovim for hobby development and as a general text editor. The plugin that I find myself using all the time is vim-surround with a couple of minor language-specific tweaks.
deleted 4y ago
[deleted]
dbrueck 4y ago
No idea if I'm typical or an outlier, but I have a couple of syntax highlighting plugins, NLKNguyen/papercolor-theme, a vim rc file with my favorite keybindings (e.g. faster navigation among splits), and a python file with some helpers for opening terminals in vim and... that's it. Every once in awhile I think I might do a fancier setup but then I lose interest. Ditto for checking out neovim. I'm sure I'd get some gains, but I guess I've sort of settled into a decent sweet spot that I haven't left for almost a decade, haha (been using vim for ~25 years total).

deleted 4y ago

[deleted]