8 ms·
What is it that prevents the rest of the vim community from adopting neovim? From what I can observe, a great deal already have. But for the folks holding out,
by fortunateregard 3y ago
What is it that prevents the rest of the vim community from adopting neovim? From what I can observe, a great deal already have. But for the folks holding out, what is it that outweighs all that neovim has to offer?
- ALoverOfLats 3y agoCan’t speak for everyone but in my day to day most systems I work with already come with vim preinstalled or more convenient to install than neovim. I’d rather just pull my vimrc (If I even have to) and get down to editing quickly.
- suprjami 3y agocscope support
- sdfghswe 3y agoFrom my admittedly somewhat limited experience, neovim felt a bit more sluggish to launch. Not a good sign.
- petepete 3y agonvim --clean --startuptime /tmp/neovim 003.174 000.001: --- NVIM STARTED --- vs vim --clean --startuptime /tmp/vim 004.274 000.001: --- VIM STARTED --- Maybe your config had an impact on it, but config-free they're incredibly close.
- oblio 3y agoInertia. Such base programs basically need to go through the Debian packaging gauntlet if they want to succeed. What I mean by that is that generally they need to persuade distros to be anointed the "official" tool, i.e. Debian or Fedora would have to select Neovim as the new default text instead of Vim. Then you need a few years for the changes to trickle down everywhere: Debian -> Ubuntu-> Mint -> ..., Fedora -> RHEL, ... After that distro releases need to be cut and people need to upgrade. I think a full cycle, where a tool becomes ubiquitous if it gets adopted in the base installs, is probably 10 years. See systemd.
- user3939382 3y ago> Inertia. At some point I tried to switch and some setting broke in my config (mouse mode?) I forget what it was. It took me another 3-4 years before I tried again.
- trealira 3y ago> What I mean by that is that generally they need to persuade distros to be anointed the "official" tool, i.e. Debian or Fedora would have to select Neovim as the new default text instead of Vim. You're probably right. However, I think it's more likely that the Linux distros drop Vim entirely and make Nano the default editor than that they replace Vim with Neovim. The BSDs have nvi as the default editor, IIRC, so they won't need to change anything.
- layer8 3y agoNano already is the default editor (via /etc/alternatives/editor).
- planede 3y agoIn what sense vim is default in Debian?
- deleted 3y ago[deleted]
- 3y ago
- mrzool 3y agoUbiquity. I have Vim on every machine I log into without installing anything extra.
- infinitezest 3y agoIn my experience, Nvim and Vim are similar enough that I don't have any trouble SSHing into any server with Vim and using it after using Nvim all day for development. So far Nvim has been a purely opt-in experience for me.
- rgoulter 3y agoWith caveats: - Different servers may have different versions of the program. Some distros are very "stable" and have very old versions of programs. - It's common (especially for vim) for users to have significant configuration files to make use easier.
- enriquto 3y ago> what is it that outweighs all that neovim has to offer? You should ask, and answer, the question in reverse. What does neovim offer me, as a regular vim user? I don't see anything particularly interesting for my usage, so I don't have any reason to change. Also, some features are missing (like gvim-gtk, that I enjoy using to edit LaTeX occasionally). Furthermore, as of today, plain vim has an aura of venerability due to Bram's legacy that neovim cannot match. So I'll stick with vim. It would make sense to port back some of the most popular neovim features into vim. It is a good thing to have innovative forks that experiment aggressively with new features.
- infinitezest 3y agoMaybe not important to some but the ability to use Lua over VimScript is a big win in my opinion. In fact, I use a mix of thr two where necessary.
- pmoriarty 3y agoHow much of the rest of the vim ecosystem is Lua-based, though? As far as I know it's still mostly vimscript. Vimscript's dominance in vim is one of the things that got me to switch to emacs when I got interested in Lisp and Scheme more than a decade ago. Sure, even then I could write scripts for vim using Vim's scheme compatibility mode, but I'd probably be one of the only ones doing so. Pretty much everyone else was using vimscript. In Emacs the whole ecosystem is in eLisp, so I'd feel right at home there, could naturally integrate other eLisp codebases/projects, could easily get help on anything related to working with eLisp in emacs. If I'd written scheme scripts in vim my work would always be a second-class citizen in the vim ecosystem. How's the vim ecosystem now? Is vimscript still dominant?
- ftaghn 3y ago> How's the vim ecosystem now? Is vimscript still dominant? You can have a full neovim experience with all sorts of modern extensions without using a single line of vimscript. Some people even replace their init (neovim's vimrc) with lua, but I am of the opinion that it is a step too far, as lua isn't particularly adapted to writing configuration files and the result is too verbose to my taste.
- zelos 3y agoI've switched to Neovim, but there doesn't seem to be a macOS UI nvim client that's quite as polished as MacVim.
- OJFord 3y agoWell, why should I? I don't need a reason not to do everything, by default I'm not doing things, it's changing from status quo that requires a reason.
- rgoulter 3y agoIt's easier to maintain one codebase than to maintain two forks. If development of vim dropped and neovim was nominated as its successor, I'd think most vim users would be just fine.
- OJFord 3y agoYes, if vim were unmaintained I would switch, that would be a reason to change. But it's not, or at very least hasn't been, so I haven't, that hasn't been a reason to.
- halostatue 3y agoNot those of us who gvim/MacVim. Give a real alternative to those instead of the many quarter-implemented GUI shells that are really no better than running Electron, and the switch might be able to happen.
- yjftsjthsd-h 3y ago> It's easier to maintain one codebase than to maintain two forks. Not necessarily; if the two codebases are maintained by groups of people with incompatible ideas about how the code should work and what it should do, then keeping things separate is much easier. > If development of vim dropped and neovim was nominated as its successor, I'd think most vim users would be just fine. Agreed; they don't diverge that much from an end-user's perspective.
- tambourine_man 3y agoFrom what I remember, NeoVim drops vi compatibility mode. vi is part of POSIX. That alone would be a reason to mantain Vim as a modern superset of vi.
- revscat 3y agoNeovim is a superset of vim, so this argument applies to both.
- johncoltrane 3y agoNo, Neovim is not a superset of Vim. Vim has things that Neovim doesn't have and vice-versa.
- marcthe12 3y agoNeovim remove set compatible (hardcodes set nocompatible). Vim support the POSIX vi via that option.
- tambourine_man 3y agoNot quite. Vim is vi compatible by default. You have to explicitly opt in for the newer behavior.
- rgoulter 3y agoIn what circumstances would you run `vi` and find yourself upset that you end up in `vim`?
- tambourine_man 3y agoYou won’t, but vi is scriptable and part of POSIX. It’s a basic infrastructure that you don’t want to break.
- rgoulter 3y agoApparently the original vi isn't POSIX compliant; nor is vim. https://vimhelp.org/vi_diff.txt.html#posix https://vimhelp.org/vi_diff.txt.html#posix I think "if the script worked before, I want it to work later" has much more practical weight. Though, on the other side of practicality, I've heard sed, awk, and perl suggested for manipulating text in bash scripts far more than I've heard of vi recommended for the task.
- plugin-baby 3y agoI tried switching recently, mainly because I wanted treesitter. I couldn’t get it working after half a day messing about, a lot of documentation seemed out of date, and I don’t think my standard plugins + .vimrc worked out of the box. My main focus is getting things done, not fiddling with configs and versions, so I gave up. I figure I’ll try again in a couple of years if it’s still tempting.
- gorjusborg 3y agoWeird. That hasn't been my experience at all. I copied .vimrc to .config/nvim/init.vim, did a :PluginInstall and was up and running.
- colordrops 3y agoI fiddled with it for half a day 5 years ago to get it working and have reaped the benefits for 5 years.
- h11h 3y agoMacVim and gVim. I've looked at neovim and there are many GUI options (paradox of choice), some of which I've tried, but at the end of the day, I'm more comfortable with what I'm already familiar with.
- rmwaite 3y agoLikewise. I’m a heavy CLI user but gVim/MacVim are so entrenched in my workflow that the lack of a stable GUI for Neovim made it pretty much a nonstarter for me.
- veilrap 3y agoAs some one who only uses vim/neovim in a terminal window - what’s the advantage of having GUI support in vim? Mouse support in my terminal seems fine, even over ssh. Being able to do things like run it inside of a tmux session has always made it seem like the GUI would be a step back?
- ciupicri 3y agoYou can use gVim as a Notepad on steroids. You have the simplicity and familiarity of Notepad combined with the power vim, e.g. search & replace using regular expressions, syntax highlighting, the ability to delete 5 words by typing ESC d 5 w, plugins like fugitive and so on. I can't select text in neovim by pressing Shift and arrow keys. I can't copy text by pressing Ctrl+C.
- sigzero 3y agoThis is my biggest hurdle as well. The UI not being part of the core is a non-starter for me and I have tried several of the neovim ones.
- w0m 3y agoI did the Vim -> NeoVim switch a while back (pre-vim9script) and lack of standardized GUI is a non trivial issue. There are solution(s) - but allof them have had too much friction to fit in a workflow for me. Definitely a concern.
- svlasov 3y agogvim and vimscript9
- beej71 3y agoIf neovim had the same keystrokes to move out of a terminal window as it does to move out of editor windows, I'd switch. But as it is, it's super clunky compared to vim. I know about rebinding to alt, but that doesn't work in all my terminals. So for me, it's that one lousy thing that keeps me from switching. And if someone knows the magic setting to make it mimic vim, please let me know.
- imbnwa 3y agoI hear this and the workaround has been opening terminals in a floating window. The “toggleterm.nvim” plugin wraps a bunch of good behavior around this.
- kzrdude 3y agoWhat keystrokes does vim use for this? I've never been a big user if terminals inside vim
- deleted 3y ago[deleted]
- ansible 3y agoI've never used those features, and instead rely on GNU screen (or `term`) to manage my terminal windows. Sometimes I also use horizontal / vertical splits with GNU screen, but it is a bit clunky.
- QuadmasterXLII 3y agoFor better or for worse ive ended up with a workflow heavily dependent on sending vim registers to the terminal
- arp242 3y ago- It's not backwards compatible. - Features I find useful have been removed. - I dislike Lua, and significantly prefer Vim9Script. - Gvim is useful at times.
- nequo 3y agoOut of curiosity to better understand the ways in which Vim can be used: > Features I find useful have been removed. Which ones specifically? > significantly other Vim9Script What do you like more in Vim9Script? > Gvim is useful at times. What are your use cases for the GUI?
- arp242 3y agoI'm pretty sure I wrote a long comment about all of this at some point, but I can't seem to find it right now; this is the closest: https://news.ycombinator.com/item?id=21954164 https://news.ycombinator.com/item?id=21954164 If I look at some Lua plugins and compare that to some of my Vim9Script (or even "legacy VimScript") plugins then I think /Vim9?Script/ "wins" hands-down; it's just much more convenient for programming an editor. It also doesn't help that IMHO Lua isn't all that great of a language to start with – it's not horrible either, just not great. On Windows gvim works loads better (even on Unix systems gvim is arguably better, because terminals kind of suck and you run in to loads of graphical and input limitations pretty quickly). But in general: neovim doesn't offer me anything I want or need, I will have to spend time on migrating (e.g. my vimrc would error out, I need to deal with changed defaults, etc.), and for most things I prefer the "highly compatible" attitude from Vim/Bram, which is a trade-off that's not without its downsides, but I really like it (for most software).
- cossatot 3y agoPersonally, I do heavy coding and writing in Neovim (with more extensive config, like LSP and Copilot), but I use macvim and gvim (depending on which OS I'm using) for quick edits or file viewing, because I often need to open files from Finder or Nautilus and I don't have a terminal open in that directory.
- ciupicri 3y ago
- jzb 3y agoLoyalty? Inertia? I never felt like there was a reason to switch. I admired Bram’s work on Vim, still do, and didn’t see any benefits to switching. Still don’t, as long as the rest of the Vim dev community are willing and able to carry it forward. For my purposes, Vim is complete. I don’t require new features, as long as it is maintained and runs on modern OSes.
- deleted 3y ago[deleted]
- kps 3y agoEvery time I've tried it, something was missing or broken. Currently it's at least :! which breaks apparently because it tries to do something ‘clever’ and complicated, whereas vi and vim just run the command. (I can live without cscope, since I no longer do significant C and mlcscope has been dead for aeons, though it's shocking that LSPs are still less capable in some respects.)
- minusf 3y agonot a heavy :! user, what i used there worked, but afaik neovim recommends :te . that's one of the bigger differences. neovim was very proud to have a fully integrated terminal
- kolme 3y agoI would need to migrate my chunky config files. Some issues should be easy (moving files to ~/.config), some other trickier (vim-specific functionality). But alas, the motivation is not big enough for me to invest the effort. Some features I'd like from Neovim are built-in LSP (but Vim has that thank to plugins), and tree-sitter based syntax highlighting. That's not enough for me to move to Neovim.
- massysett 3y agoMy Vim needs are very modest. I just don’t need anything Neovim has. It’s complication I don’t need. If Vim got no new features, I wouldn’t care. If Vim became unmaintained but still available from distributions, I’d still use it. If Vim became unavailable (e.g. due to lack of maintenance) I’d be more likely to switch to nvi than Neovim. I could probably switch to nvi now, but I have no reason to.
- throwaway290 3y agoFWIW you can use Neovim like Vim with your existing config, without any of the other stuff. That made the switch easy for me. Of course this means you'd rely on Neovim maintainers honoring that compatibility in future...
- massysett 3y agoOne of the things I really like about Vim is how it maintains compatibility with Vi. The manual obsessively points out features Not in vi. It retains some ill-advised things like :Print because Vi had them. Ancient platforms still work, supposedly. I care about this not because I used Vi (I never have) but because it’s less likely that some new Vim with a newer distribution release will do something I don’t expect. Vim does want I need it to do. I don’t want it to change. Neovim on the other hand exists entirely to change things. That’s all well and good. I just don’t want it. My editor is complete.
- throwaway290 3y agoUhm if you read my comment it is specifically about how nvim doesn't change the preexisting behavior of vim. And if I were to believe you then compatibility with vim means compatibility with vi
- massysett 3y agoI did read your comment word for word: “Of course this means you'd rely on Neovim maintainers honoring that compatibility in future.” I knew that maintaining compatibility was extremely important to Bram Moolenaar. I also knew that Neovim made a big deal out of removing “cruft” and old stuff they decided no one needed. I preferred Bram’s values.
- layer8 3y agoBy now the two have diverged enough that switching configurations between both is an issue. Vim is still much more widely available (installed by default) than Neovim, which makes it the obvious choice to maintain your configurations for if you don’t specifically care about Neovim features. Furthermore, additions like Lua support, while pragmatic, make Neovim feel less organic to me.
- ansible 3y agoIn that vein, you are probably fine with whatever version of Vim is installed by your distro. But if you want LSP support for more cutting-edge stuff (like Rust), you probably need to install the latest release of Neovim by hand, not using the OS packaging system. Because stuff is changing too fast.
- BanazirGalbasi 3y agoI feel like I've said the same thing here 3-4 times now, but for some of us it's about what's the most minimal setup required to use the tool. As a sysadmin, I want to be used to the most common tools and configurations that will be on a server without having to take the time to install something new. I could include NeoVim in my Ansible configs for setting up new servers, but generally servers are kept lean so I would rather just use vi/vim for basic edits anyway. I do use NeoVim with a lightly-customized LazyVim setup on my personal desktop, but I don't use it much differently than I use Vim at the moment. I'm not a power-user, just someone who's comfortable enough with the keybinds that I leave :w everywhere when using a non-vi editor.
- guhidalg 3y agoSerious question: how is neovim “heavier” than vim?
- thefifthsetpin 3y agovim often ships with the base image, so you'd be comparing installing neovim on top of that to installing nothing.
- tomwheeler 3y ago> for some of us it's about what's the most minimal setup required to use the tool. That's was the case for me. When I moved from vi to vim 25 years ago, I devoted a lot of time to customizing it for maximum developer efficiency. Around that time, I got a job where I regularly used five different HP/UX machines, a couple of Solaris boxes, and a few other random machines. At the next job, it was HP/UX, AIX, and IRIX. Few of those machines had vim at all, let alone a version compatible with the setup I had on Linux. I eventually stopped doing the fancy things and settled into using plain vanilla vi, knowing that it would at least work consistently on every machine I used.
- stcroixx 3y agoFor my use case of simple editing, vi was feature complete like 30 years ago. I don't have any preference at all what open source project build implements those features.
- nemetroid 3y ago$ rpm -qi neovim package neovim is not installed $ dnf search neovim No matches. I don't have anything against it, but prefer being able to use the same tool across environments.
- berkes 3y agostrange. > Neovim is available through EPEL (Extra Packages for Enterprise Linux) from https://github.com/neovim/neovim/wiki/Installing-Neovim#centos-8--rhel-8 https://github.com/neovim/neovim/wiki/Installing-Neovim#cent... > Neovim is in Fedora starting with Fedora 25 > sudo dnf install -y neovim python3-neovim from https://github.com/neovim/neovim/wiki/Installing-Neovim#fedora https://github.com/neovim/neovim/wiki/Installing-Neovim#fedo...
- nemetroid 3y agoNot so strange if you’ve met the kind of sysadmins that don’t enable EPEL.
- syndicatedjelly 3y agoI would like to use Neovim, but it's not as fully featured as VSCode is, so when I need to boot up something more powerful than Vim, I go to VSCode instead.
- highpost 3y agoThere is an excellent NeoVIM extension that integrates NeoVIM into VS Code. https://marketplace.visualstudio.com/items?itemName=asvetliakov.vscode-neovim https://marketplace.visualstudio.com/items?itemName=asvetlia... Best of both worlds.
- syndicatedjelly 3y agoI actually do use the Vim extension in VSCode, it's excellent
- andrewla 3y agoFor me, it's the use of Lua. I switched to neovim in no small part for the sane defaults, the XDG layout support, and the async/terminal stuff (and I found the code simplification, addition of tests, and removal of ancient legacy stuff to be very appealing). The terminal and async stuff has been "backported" to vim, as it were. But the plugin ecosystem is diverging. The other items are still open, and maybe those will move forward. At this point Vim9 is the clearly superior language (don't hate me) since it's very domain-specific, while Lua has only very primitive hacky support. But the plugin ecosystems have diverged -- I don't see NeoVim coming back home without native Lua support, and I definitely don't want native Lua support in vim.
- conor- 3y agoFor me it's that Vim offers me enough to satisfy what I want out of a development experience and vim is also installed everywhere which means I can carry my setup around to pretty much any machine (including servers when doing remote administration). Since Vim 8 launched with a built-in package manager I'm able to store my vimrc and any extensions in git and easily grab it on any new machine I'm on. The level of effort required for me to convert to Lua and adopt newer nvim version of plugins I use seems too high relative to the benefits.