(Habit) Unfamiliar: 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 in my senior year why I bothered with vim, I would have said 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 impressed me. I searched extensively and ended up using vimplus. It was also the first star I left on GitHub. But this was just a superficial experience. On one hand, the computer I had in college was bought for over 2000 yuan in my freshman year, and using vim in a virtual machine always felt "laggy" to me. On the other hand, I didn't explore vim further and didn't understand the shortcuts or plugins. Among the many capabilities provided by vimplus, I only used the themes.

After starting work, influenced by my colleagues, I installed the vim plugin for PyCharm, but I only became proficient in switching between normal mode, insert mode, and command-line mode, relying on the arrow keys for cursor movement.

The change happened when I got a 13-inch MacBook Pro. Its arrow keys were really small and "tucked away", making it painful for me to move the cursor every time. Helpless, 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 virtual mode, text objects, marks, and window operations that made coding easier for me. I managed to stay away from the mouse and arrow keys when writing code.

If you were to ask me now why I bother with nvim, I would say it's to stay away from cracked software. I use a legitimate JetBrains IDE at work and a pirated version at home, which is somewhat unsatisfying. Although I switched from vim to nvim a long time ago, it was only in April of this year that I learned it supports Lua configuration, which reignited my ambition to switch from PyCharm to nvim.

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 I rely on in an IDE at 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 (variables, functions, or class references)
Directory tree
File name and content search

These are the capabilities 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 I know 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.

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

I have achieved all of these. In other words, I can now program using nvim. However, the reality is that I only use nvim at home during this stage, and 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 I rarely use during programming, and they are "non-essential" but not urgent.

With NvChad, executing git blame is :Gitsigns toggle_current_line_blame; git diff for local files is :Gitsigns diffthis; and code folding is natively supported in 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 can now rely on nvim for development at 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 by the author have not been implemented yet. I encountered obvious bugs while using it and even fixed two of them. I have a bit of selfishness in wanting to leverage its imperfections to learn how to write Lua plugins.

Not Necessary and Not Urgent#

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

Homepage: goolord/alpha-nvim
Keyword highlighting: 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, I have added very few additional plugins, as I believe in "quality over quantity".

Not Used to#

There are still some areas where using nvim for development at work is not smooth.

Unfamiliar Code Checking#

Our Python project does not adhere to PEP 484, which causes pyright to give a lot of error and warning messages during code checking. To reduce the interference, I have to turn off strict checking:

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

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

Unfamiliar Code Reading Experience#

When I need to jump into a third-party package that my 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 jumping into a dependency package, but 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 dependencies and belong to necessary but not urgent features that can reduce work efficiency. Once I encounter them, I can only obediently 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 at my own pace. If I can't solve it in the end, maybe I will write my own Lua plugin. If it were in the era of Vimscript, 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)