cscope support

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

From my admittedly somewhat limited experience, neovim felt a bit more sluggish to launch. Not a good sign.

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

3/4 seconds??? Something's wrong with your system, right?

They're milliseconds!

I abbreviated the output, if you run the above command and check the file, at the top it says

   times in msec

Oh that's awesome actually.

Inertia.

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.

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

Nano already is the default editor (via /etc/alternatives/editor).

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

In what sense vim is default in Debian?

It’s not, Nano is.

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

> You should ask, and answer, the question in reverse. What does neovim offer me, as a regular vim user?

Well, one of the goals of neovim was to make it easier for new people to contribute.

So, there's an obvious feature you might be overlooking: the project surviving past its creators passing.

Beyond that, async, lua, lsp and treesitter support are other things neovim brings to the table. I don't use vim much anymore, but I know that neovim incorporated them first. If vim did follow on some of those innovations, consider how long it might take for new vim maintainers to get to a point where Bram needed to be to keep up, without his guidance.

I wonder if there is a need for both vim and neovim in the future. Neovim was born out of wanting to do similar things to what the vim maintainers are considering.

I know you listed Lua already, but it's important to stress that. Bram _did not_ want Lua as the main scripting language, and created Vim9 Script as a "better VimScript" instead. That's a stark difference in the direction for the project, and it signals to me that Vim is not meant to reintegrate with Neovim. It's no longer a question of Vim catching up with Neovim.

However, this was Bram's vision. We don't know how the new leadership will affect that.

> Vim9 Script as a "better VimScript" instead. That's a stark difference in the direction for the project

Great point. I wasn't following vim much, so didn't know the context around the language changes.

That does seem like a core philosophical difference. I'm interested to see what the future holds.

it's not quite just a "better vimscript" language it's an incompatible language, if it was just improvement on top of the existing vimscript it would have been fine i think but what people are complaining about is if you are going to break compatibility why not choose an existing language like lua

Yes, you're right. That's what I meant, but I should've highlighted the incompatibility aspect.

Neovim's language server integration is a killer feature that got me to switch.

Absolutely! I started using LunarVim packages+configs on top of neovim), looks like a couple of years ago according to my work notes, and the LSP has been a huge improvement in my editing.

Can you explain the benefit? I'm not familiar with the feature.

Basically neovim can act as a client to a variety of different language servers (https://github.com/neovim/nvim-lspconfig/blob/master/doc/ser...) which give neovim IDE capabilities. This can be done in original Vim also but requires external plugins which can be a pain to compile and install. Neovim has it built in.

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

How 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?

I think the ecosystem is more or less splitting. As a user, not dev, it looks like neovim "distributions" are mostly lua and would be feature complete (with some substituted plugins) even if 100% lua was enforced.

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

I have mainly lua config but just put in some vim files where I put bits and functions that were already written in vimscript.

Ah you see, you just wrap that lua in a lisp in some terse macros and there you go, instead of writing `:set formatoptions+=j` (yuck, vimscript!) or `vim.opt.formatoptions:append"j"` (vom, lua!) you can write the clearly superior `(opt formatoptions +j)` (heck yes, ivory tower).

My config is a horrible frankenstein of both.

I use lua when examples are in lua or when I need some "logic" (such as assigning defaults to a var and then passing that around/overriding). And that's embedded in vimscript.

I don't really like either. VimScript has always been a horror to me, eventhough I've been using vim for some 20 years now, almost exclusively. Lua is "that thing that I should really sit down and learn. But not now, I've got stuff to finish".

What does lua -for an end user- offer that something like yaml+python cannot offer? I really won't mind setting all sorts of flags, defaults and vars from some init.yaml, and then have some init.py to handle the few places where I do need actual logic. Why was lua picked, why did vim build its own language and not move to an existing one for its config? Am I just weird for never sitting down and learning lua? Or vimscript? Or both?

independently of vim configuration, lua is a cute general-purpose language worth learning in itself. It is much simpler than python, and the documentation is outstanding.

Lua is faster than Python and also easier to embed in vim [1] which are both big advantages for the end user. It means fast plugins and no hassle with having the correct python version.

Why Bram build is own language and then doubled down on it with vimscript9 I don't really understand.

[1] https://neovim.discourse.group/t/why-was-lua-chosen-for-neov...

> Why Bram built his own language [...] I don't really understand.

What language would have you chosen in 1991 instead of creating vimscript? The vimscript language is a very natural extension[0] of Bill Joy's "ex" language, that was used in vi since 1976. The history of vimscript is not weird, it's just a fairly natural continuation of existing practices. Vimscript9 is a least-friction update for modern times.

[0] https://en.wikipedia.org/wiki/Vim_(text_editor)#Vim_script

I should have written I don't really know anything about.

According to your link scripting was only available from '98, at which point Lua and Python were already around, but then I don't know how viable that would have been. Funny you say that about ex, because I find running ex commands from vimscript the most clunky thing about it.

In my opinion the least friction for the ecosystem would have been to follow neovim and adapt Lua.

Neovim's adoption has been incredible. Virtually every major vimscript plugin has either been ported or overtaken by a Lua-native alternative in the Neovim ecosystem.

I've also seen neovim plugins written in fennel [0], so if you want something lispy, that's possible now.

[0]: a Lisp that compiles to Lua, https://github.com/bakpakin/Fennel

> the ability to use Lua over VimScript

The Neovim people went a bit further with the integration, but you've been able to use Lua with Vim for like 20 years or so, and you can use it to write perfectly functional plugins with it. Probably the main difference is that in Neovim Lua is always guaranteed to be available, which isn't the case for Vim.

One of the big ones for me was Wayland support in neovim-gtk (https://github.com/Lyude/neovim-gtk), which therefore, unlike gvim, fully supports fractional scaling.

Ubiquity. I have Vim on every machine I log into without installing anything extra.

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

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

I've switched to Neovim, but there doesn't seem to be a macOS UI nvim client that's quite as polished as MacVim.

That's why I still keep vim updated on my mac system. For nvim, the closest one I found is VimR.

I'm using Neovide for now, which seems to be gathering momentum, but I still miss MacVim. I had a fair few crashes with VimR that ruled it out for me.

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

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

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

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

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

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

Neovim is a superset of vim, so this argument applies to both.

No, Neovim is not a superset of Vim. Vim has things that Neovim doesn't have and vice-versa.

Neovim remove set compatible (hardcodes set nocompatible). Vim support the POSIX vi via that option.

Not quite. Vim is vi compatible by default. You have to explicitly opt in for the newer behavior.

In what circumstances would you run `vi` and find yourself upset that you end up in `vim`?

You won’t, but vi is scriptable and part of POSIX.

It’s a basic infrastructure that you don’t want to break.

Apparently the original vi isn't POSIX compliant; nor is vim. 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.

Yes. If you need to do some text manipulation in a shell script, `sed` or something like that is what I'd reach for first. (I haven't used `awk` or Perl for quite a while.) I'd think even `ed` would be a more straightforward choice than `vi`.

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

Weird. That hasn't been my experience at all.

I copied .vimrc to .config/nvim/init.vim, did a :PluginInstall and was up and running.

I fiddled with it for half a day 5 years ago to get it working and have reaped the benefits for 5 years.

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

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

As 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?

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

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

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

gvim and vimscript9

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

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

What keystrokes does vim use for this? I've never been a big user if terminals inside vim

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

For better or for worse ive ended up with a workflow heavily dependent on sending vim registers to the terminal

- It's not backwards compatible.

- Features I find useful have been removed.

- I dislike Lua, and significantly prefer Vim9Script.

- Gvim is useful at times.

Out 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?

I'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

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

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

> What are your use cases for the GUI?

I don't want to type like it's 1976. I want something simple and easy to use similar Notepad / gedit, but that still powerful when needed.

From what I've read[1], vim9script was pushed and developed almost exclusively by Bram. With him, a lot of knowledge about its internals and vision for its future dies.

[1]: https://github.com/vim/vim/discussions/12736#discussioncomme...

You're correct it was very much a "Bram project", but that doesn't mean the language needs to die with him: other people can work on it (and already have!) Vim9Script is also "finished", more or less, as "finished" as languages get anyway. The features Yegappan mentions are what we might call "optional features".

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

neovim became unusable for me when they removed cscope support, which I’ve depended on for my work for almost 15 years now.

That prompted me to return to regular vim and I’ve been perfectly happy since.

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

not 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

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

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

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

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

Uhm 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

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

and I responded to your "exists to change things". Vim also exists to change things, otherwise it wouldn't exist if Vi was enough. but it is compatible and from my experience nvim is compatible with vim.

Having to rely on them for that is a downside, but I guess you are free to fork nvim if they abandon that promise...

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

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

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

Serious question: how is neovim “heavier” than vim?

vim often ships with the base image, so you'd be comparing installing neovim on top of that to installing nothing.

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

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

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

strange.

> Neovim is available through EPEL (Extra Packages for Enterprise Linux)

from 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#fedo...

Not so strange if you’ve met the kind of sysadmins that don’t enable EPEL.

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

There is an excellent NeoVIM extension that integrates NeoVIM into VS Code. https://marketplace.visualstudio.com/items?itemName=asvetlia...

Best of both worlds.

I actually do use the Vim extension in VSCode, it's excellent

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

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