I am an Avid Vim User, Finally Migrated to Neovim! How does it work, what do I gain from it?

Having migrated to Neovim, I will give you some feedback and give you the keys to understanding and succeeding in your migration to Neovim! First of all, a little context and history.

Vim, the essential

Who doesn't know Vim, if only through jokes about how to quit it? And for good reason Vim - or often its predecessor Vi, which has been around for over 44 years - often remains our most faithful ally, especially in minimal environments.

Developed in 1976 by Bill Joy, Vi was a real revolution, notably by introducing the use of the entire screen, which for the time was a real revolution. It must be said that at that time the majority of text editing was done using ed, from which Vi and Vim will inherit the modal aspect.

A decade later, a certain Vi user Bram Moolenaar sought to port it to the Amiga. He ended up developing version 1.0 of Vim in C in 1988. This version was intended to be an improved version of Vi, hence the acronym (VI iMproved).

Vim continues to evolve from year to year still in the hands of Bram Moolenaar, even if the pace of this evolution has decreased over the last 2 decades. This slowdown can be accentuated by the very closed contribution management policy. The proposals are complex to have the creator accept.

NeoVim, reinventing yourself without forgetting yourself

We might as well admit it, Vim development issues ended up impacting the user community. So much so that in 2014 part of the Vim community embarked on the NeoVim project, notably launching a fundraiser which was a success. The goal of NeoVim is simple: to create a more modern, extensible Vim, with better integrations, and of course a more efficient development community.

From December 2015, version 0.1 of NeoVim was released, offering support for a very large part of Vim's functionalities. The community will quickly expand and the number of users will increase. The versions will also follow one another, regularly offering new features. To give you an idea, today we are at version 0.10.

In short, a project which has already proven itself and which continues to evolve by gaining more and more features.

Why am I using Vim / NeoVim in 2024?

Except for specific development needs, I assume that the majority of you use VSCode, although I have no doubt that the more hipsters use an IDE from the IntelliJ suite. First of all, yes, Vim/Neovim are not IDEs, but code editors. That's not to say they can't fulfill the same needs as an IDE once custom configuration and plugins are added. In short, yes, in my opinion and for my use, it is comparable in this case.

I haven't always used Vim, I started on Eclipse in my early years when I was into Java EE development. Like many people, I suppose, I had the impression of using heavy software, full of overpowering features. But ultimately having the use of too little. Especially since at that time, I was still a student, I might as well tell you that when you move from Java to system-oriented C, your IDE is no longer suitable.

After that, I went to the dark side. Needless to say, I spent more time in front of a terminal than anything else, even if automation made it possible to limit manual tasks. Unfortunately, sometimes we have no choice and have to make changes often via SSH. Suffice it to say that your IDE will be of little help to you. So I did like everyone else, use Vim. At the beginning, it's complicated: modal functioning seems from another time and it feels like we are doing violence to ourselves. Over time, I found myself working largely over an SSH connection and had to start getting into Vim and Tmux, which remains, in my opinion, an excellent combo.

After this, I went back to working on my job. I could have started with an IDE, but in the end, I was starting to adapt to Vim. I wasn't an expert, but it was enough for my job. Over time, I started to get comfortable, added plugins that really changed my perception of Vim. From a very basic text editor, where the most advanced feature was syntax highlighting, I moved to an editor on steroids, with a real compression engine, Git integration, and lots of other tools. In short, everything I needed.

But around this time Atom and later VSCode gained popularity, particularly in the DevOps environment. I'm not going to lie to you: I tried it. It was at this moment that I understood two things: Vim, with my configuration and my plugins, was just as powerful in terms of functionality for my use and above all, Vim had changed the way I worked. When I say “changed my way of working”, it is, in particular, for a detail that will seem stupid to you: Vim is in a terminal. Coupled with Tmux it has become, for me, an ideal combo. The organization of my Gnome workspaces, my screens, in fact my entire work workflow ended up being focused on this. So I decided to return to Vim, while continuing to develop my configuration.

What changes daily

When I saw Neovim pass by, it seemed to me that it was in 0.4. At the time, I said to myself: “ah, another fork that doesn’t add much”. So, I stayed on Vim. Especially since version 8, released recently at that time, brought cool features, notably asynchronous support. I still followed the evolution of NeoVim from afar.

One day, a new version 0.5 of NeoVim was released, and this was, I think, a real argument to start considering migration. This update brought a lot of very interesting features. Of course a fully integrated client for the LSP (we will talk about it later), better support for Lua configuration,and a new parsing system for syntax coloring in particular (Tree-sitter).

In the end I ended up giving in and testing it in front of the list of its contributions:

• A client for directly integrated LSP
• Being able to configure in Lua: Vimscript quickly has its limits
• More open: many interesting plugins are available only on NeoVim
• Better documentation

Casually, a more dynamic community, often with a modern approach
I will spare you the bug fixes and little everyday joys, especially on the default settings, which are much less austere than Vi or even Vim. For many, this list must be vague and that is normal! Beyond the list, I suggest you take a quick tour of these new features, what they bring and especially how they work.

Lua

If you are a minimum advanced Vim user you have already encountered the famous VimScript, the language which allows you to configure your installation, but also to create plugins. It used to be an unpleasant point for a lot of people, including me. With Lua we have gained in comfort and possibilities.

I was a little afraid of having trouble at first having never used Lua, but it's quite clear and simple. To be more comfortable, I still took a few minutes to know the basics and for that I recommend this site.

One thing is still worth noting: you can have a lot of problems if, like me, you cut your code too much. Either way we can correct it, but personally it tired me out a lot for a minimal contribution so I put all my code in a file.

Small example of code in Lua:

function map(mode, shortcut, command)
  vim.api.nvim_set_keymap(mode, shortcut, command, { noremap = true, silent = true })
end
map('', '<C-D>', ':Telescope find_files<CR>')
map('', '<C-F>', ':Telescope grep_string<CR>')
map('', '<C-X>', ':NvimTreeToggle<CR>')

Packer

I have been talking about plugins since the beginning of the article, but using a simple editor doesn't involve doing everything by hand. So I have been using a plugin manager for a long time and if you don't, I strongly advise you to get started: it's very practical. I used Vim plug which was everything I like: simple and effective.

But with NeoVim, a whole new world of plugins is available to us. And among these plugins, one of them, very popular, allows you to manage plugins: it is called Packer and is not developed by Hashicorp.

This offers, in my opinion, everything I could expect from a plugin manager under Neovim:

• Developed and configured in Lua
• Manage dependencies
• Lots of installation and management options
• Manages installations through asynchronous tasks
• Supports Git especially in terms of tags

The manager works well, allows you to install, update and delete different plugins. Beyond that, it installs easily and automatically with just a few lines of Lua code:

local fn = vim.fn
-- Automatically install packer
local install_path = fn.stdpath "data" .. "/site/pack/packer/start/packer.nvim"
if fn.empty(fn.glob(install_path)) > 0 then
  PACKER_BOOTSTRAP = fn.system {
    "git",
    "clone",
    "--depth",
    "1",
    "https://github.com/wbthomason/packer.nvim",
    install_path,
  }
  print "Installing packer close and reopen Neovim..."
  vim.cmd [[packadd packer.nvim]]
end

Installing plugins is just as simple and efficient:

require('packer').startup(function(use)
  use 'wbthomason/packer.nvim' -- Package manager
    # Put all your plugins
  use { 'nvim-telescope/telescope.nvim', tag="nvim-0.6", requires = { 'nvim-lua/plenary.nvim' } } #Plugin with a dependency 
tag
end)

To interact with Packer: you just need to use the NeoVim console to execute commands, such as PackerInstall and_ PackerSync_.

Please note: Neovim having a more regular development cycle, the plugins are also often updated. If you are not using the latest version of Neovim, do not hesitate to tag the plugin installations. I had some unfortunate surprises: plugins, which, once updated, were no longer compatible with older versions of NeoVim. This is done simply as in the example given above.

LSP

One of the weaknesses of Vim, for a long time, was the quality of comprehension, more especially of the engine which allowed the editor to understand the structure of the code in order to do autocompletion or even to notice errors. Syntactic problems and so on.

This situation has already changed thanks to Language Server Protocol and the numerous implementations based on Json-RPC.
Neovim provides a perfectly functional native client, which simplifes installation, and allow us to benefit from features worthy of the most popular editors.

It should be noted that, although Neovim integrates the client, certain plugins are necessary for LSP to give you a better integration experience. I advise you:

• nvim-lsp-installer which allows you to install language servers directly from the Neovim console
• nvim-lspconfig which brings together a set of basic configurations for LSP
• cmp-nvim-lua which displays small windows for autocompletion.

If you want to verify that your editor has detected the language and is using the correct server, you can use the command: LspInfo, which will show you all the LSP client information.

It may happen that your editor does not associate a file type with the language server. In this case, you can specify it, as below:

require'lspconfig'.terraformls.setup{
    capabilities = capabilities,
    filetypes = { "tf", "tfvar", "terraform" }
}

Bonus tip, you can run a diagnostic of your Neovim, in order to identify certain problems. For this just run:_ checkhealth_.

Telescope, boosted fzf

Very often when you start customizing your Vim or Neovim, you install a plugin allowing you to display the tree structure in your editor. It's nice, it allows you to have a view of the structure, but moving from one file to another is slow. So, very quickly, we turn to Fuzzy-finder. And there, generally, we come back to life and we no longer want to leave our publisher.

Fzf is good, but as I said above, Neovim offers a lot of new plugins with new implementations. And among them, a supercharged fzf: Telescope! It allows you to search for files, and even text patterns, while offering an interface with file previews! A must have , quite simply.

Finally the version of Vim we have been waiting for?

When I decided to migrate to Neovim, I preferred to do away with Vimscripts, in favor of Lua. And looking back, I think it was the right approach. However, I must admit that I wasted a lot of time, particularly in wanting, at all costs, to divide my configuration files too much, which Lua obviously doesn't like. I ended up using a simple base I found online and adapting it to my taste. I still kept the theme which is a nice homage to Atom.io which I had tried.

Vim was clearly my main IDE / code editor, I hesitated to change for a long time, not being sure of the contribution. In the end, the transition is going well: Neovim is a great development, but it does not destroy Vim's heritage. We therefore find the modal system, the lightness, the native terminal operation and everything that makes Vim so remarkable.

Comments

[Brian Masinick]

I am sorry to inform you that Bram Moolenaar, the creator of Vim, passed away on August 3, 2023 at the young age of 62.

2 Proven, Liam (7 August 2023). "RIP Bram Moolenaar: Coding world mourns Vim creator". The Register. Archived from the original on 8 August 2023. Retrieved 7 August 2023. Source: en.wikipedia.org/wiki/Bram_Moolenaar

[Umair-khurshid]

Ah! Never heard about it.

[Chirag Aggarwal]

Great post mate! Have you tried neovim configs like lunar vim? I personally love it

[Umair-khurshid]

No, I have not but I just searched and it looks great. Thanks for the suggestion!

[Umair-khurshid]

Trust me, it's worth the hype!

[Ben Sinclair]

One of the weaknesses of Vim, for a long time, was the quality of compression

Did you mean, "comprehension"?

I like neovim as well, but some of the points you make are a bit confusing. Why do you think telescope is better than fzf? You say:

It allows you to search for files, and even text patterns, while offering an interface with file previews!

But fzf does that as well, all out-the-box!

[Umair-khurshid]

Yeah, I meant "comprehension" instead of "compression" but auto-suggest did it's thing. Thanks for pointing that out! You're right that fzf also allows searching for files and text patterns. However, I prefer Telescope because it offers an enhanced user experience wwith other Neovim features.

[Bernd Wechner]

I use vi still (usually vim in the background I guess, I dunno, I just type vi file) out of habit (I belong to that generation that was using line editors before vi came along, just after the card reader generation).

But this made smile:

Unfortunately, sometimes we have no choice and have to make changes often via SSH. Suffice it to say that your IDE will be of little help to you. So I did like everyone else, use Vim.

Not least because I used to agree, and that indeed accounted for a fair deal of my vi use. But still, for at least a decade I'd guess I would have written your note more like this:

Unfortunately, sometimes we have no choice and have to make changes often via ssh. Suffice it to say that your IDE will be of little help to you. So I do like everyone else, use sshfs!

sshfs is a dream come true. If I have ssh access, I can access the remote filesystem locally and use local (read, GUI) tools. Pufff, there went a lot of the vi use cases right there. In practice I use my desktop file browser (Nemo usually) and whatever IDEs or editors suit the task and are available to me.

[Brian Masinick]

One other point: while very extensible, both Vim and Neovim (usually executed as nvim) are extremely fast and efficient if you run them 100% stock. While still effective, as you increase the number of add-ons, it stands to reason that resource usage increases, though never to the extent of a heavy Web browser!