(Dis)comfort: Migration to nvim

Backtracking#

Before talking about migrating to nvim, I want to talk about why I started using nvim.

If you had asked me why I bothered with vim when I was in my senior year, I would have said it was to show off. At that time, I found a black horse video to get started with Python, and the instructor who taught web scraping showed off his vim skills, which amazed me. I searched extensively and finally used vimplus. It was also the first star I left on GitHub. But this time it was just a shallow taste. On the one hand, the computer I had in college cost over 2000 yuan in my freshman year, and using vim in a virtual machine always gave me a "laggy" feeling. On the other hand, I didn't know much about vim, I didn't understand the shortcuts or plugins, and among the many capabilities provided by vimplus, I only used the themes.

After I started working, I installed the vim plugin for PyCharm under the influence of my colleagues, but I only learned how to switch between normal mode, insert mode, and command-line mode, and relied on the arrow keys to move the cursor.

The change happened when I got a 13-inch MacBook Pro. Its arrow keys are really small and "out of the way," and every time I move the cursor, it pains me. Helplessly, I learned hjkl. Once you take the first step on an adventurous journey, you are destined to move forward. Maybe you can't overcome all obstacles, but you won't get further away from the finish line. So slowly, I learned about virtual mode, text objects, marks, windows, and other operations that make coding easier for me. I managed to stay away from the mouse and arrow keys when writing code.

If you ask me now why I bother with nvim, I would say it's because I want to stay away from cracked software. I use a legitimate JetBrains IDE at work and a pirated version at home, and it's not very satisfying. Although I switched from vim to nvim a long time ago, I only learned in April this year that it supports Lua configuration, and my ambition to switch from PyCharm to nvim has risen again.

As of today, I have been using nvim for programming at work for over a month, so it's time to talk about my migration journey.

Habits#

First, I identified the features of the IDE that I rely on in my work. If nvim can provide these capabilities, then switching from an IDE to nvim would be feasible. I categorized these features as necessary and urgent, and necessary but not urgent.

Necessary and Urgent#

The necessary and urgent features are:

Cursor movement
File navigation
Code completion
Viewing symbol references (references to variables, functions, or classes)
Directory tree
File name and content search

These are the capabilities that I heavily rely on during programming, and they are "essential."

Cursor movement and file navigation are operations I perform using vim plugins in the IDE, and they are naturally available in nvim. What about the others? I have been observing nvim from the sidelines for years and knew that there must be plugins that support these features. Finally, I found NvChad. I compared several nvim distributions and personally preferred NvChad because it implements the minimal feature set without being bloated. If I encounter a feature that I need but NvChad doesn't have, I just need to learn how to add custom configurations to NvChad. So I immediately created a custom directory under ~/.config/nvim/lua/ to store my custom configurations.

Under NvChad, opening or closing the directory tree only requires C-n; file name search is <leader>ff, and file content search is <leader>fw; viewing symbol references is gr. Code completion requires configuring lspconfig:

I have achieved all of these. In other words, I can now use nvim for programming. However, the reality is that I only use nvim at home during this stage, and I still use the IDE at work.

Necessary but Not Urgent#

The necessary but not urgent features are:

Symbol tree
Git blame
Git diff for local files
Window sessions
Code folding
Bookmarks

These are the features that I rarely use during programming, and they are "essential but not urgent."

Under NvChad, executing git blame is :Gitsigns toggle_current_line_blame; git diff for local files is :Gitsigns diffthis; code folding is already supported by nvim (:help fold).

Other features are implemented through plugins:

Symbol tree: symbols-outline.nvim
Window sessions: rmagatti/auto-session, zwhitchcox/auto-session-nvim-tree
Bookmarks: ChristianChiarulli/bookmark.nvim

With this stage completed, I now rely on nvim for programming in my work. I want to clarify in advance that ChristianChiarulli/bookmark.nvim is not a great choice for bookmarks. It is relatively new, and many of the planned features have not been implemented yet. I encountered obvious bugs while using it and fixed two of them. I have a bit of selfishness because I want to use its imperfections to learn how to write Lua plugins.

Not Necessary and Not Urgent#

Not necessary and not urgent are some features that I discovered while researching nvim plugins but haven't used in the IDE. They are "nice to have":

Homepage: goolord/alpha-nvim
Highlighting keywords: Mr-LLLLL/interestingwords.nvim
Quick cursor movement:
- ggandor/flit.nvim, ggandor/leap.nvim
- folke/flash.nvim

I am currently in the exploration stage. I have tried many plugins and deleted many of them. Apart from the integrated features of NvChad itself, I have added very few additional plugins, essentially aiming for "quality over quantity."

Unfamiliarity#

There are still some aspects of using nvim for development at work that I am not comfortable with.

Unfamiliar Code Checking#

Our Python project does not follow pep484, which causes pyright to give a lot of error and warning messages during code checking. To reduce the interference, I can only turn off strict checking:

settings = {
    python = {
        analysis = {
            diagnosticMode = "openFilesOnly",
            typeCheckingMode = "basic",
            diagnosticSeverityOverrides = {
                reportGeneralTypeIssues = "none",
            },
        },
    },
}

Although there are still "false positives," it is barely usable.

Unfamiliar Code Reading Experience#

When I need to jump into third-party packages that our project depends on, the directory tree does not follow the switch. This is because I have left the project's root directory, and the nvim-tree/nvim-tree.lua configuration is set to not update the root directory (update_root = false). After changing it to true, the directory tree follows the switch when I jump into the dependency package. However, when I press C-t to exit, the root directory of the directory tree becomes the directory of the current file, not the project's root directory. And it seems that I can't go back to the project's root directory.

The Bekaboo/dropbar.nvim plugin can solve the problem I encountered, but it seems that it cannot run in Windows WSL. Although I have a Mac computer, I don't want my development tools to depend on a specific operating system. So I gave up.

At the same time, I am also writing Go code. Goland supports viewing which structs implement a certain interface and which structs implement a certain interface. Currently, I haven't found a similar plugin.

These frustrations only arise when I deeply read the code of the dependencies. They belong to necessary but not urgent features and can reduce work efficiency. Once encountered, I can only reluctantly open PyCharm or Goland. Fortunately, they are very rare.

Conclusion#

For me, completely eliminating JetBrains IDE from my work will take some time, at least until I resolve the "unfamiliar" experience in nvim. Fortunately, I am not in a hurry, and I am migrating to nvim in a relaxed manner. If I can't solve it in the end, maybe I will write my own Lua plugin. If it were in the vimscript era, I wouldn't dare to make such a big statement (laughs).

If someone asks: Why don't you use VSCode? I would answer that it's a personal choice.

(My nvim configuration: https://github.com/youguanxinqing/Config/tree/master/vim/nvchad)