Nanologs on Gaspar Vardanyan

Do You Read Diffs Before Committing?

Sun, 14 Jun 2026 17:45:03 +0400

Do you read diffs before committing? If no, maybe because it’s not a great experience reading plain diff in terminal? Delta makes diffs more readable as it does in the “Staged changes” window in this screensot:

I use delta in LazyGit (the rest of the git related stuff in the screenshot). Two separate programs doing different things “mixed” together. LazyGit is a TUI wrapper on git. It shows changed files, whether they are staged or not (as in the “Files” window in this screenshot), worktrees, branches and the diff, helps with staging/unstaging by hunks, merging, rebasing, etc. By default LazyGit displays plain git diff. You can configure git to use Delta as diff pager. This way both LazyGit and the “git diff” command use Delta to display the diff.

Furthermore I use lazygit inside NeoVim. When I want to commit and push changes I open lazygit with “gl”, check the diff, fix things if necessary, stage files, commit and push from LazyGit.

NeoVim developers don’t have to worry about git support. When git support (or something else) is broken, other IDEs can give the priority to other things and delay the fix. NeoVim cares only about editing the text. LazyGit and Delta are separate projects, they don’t stop each other.

Furthermore in NeoVim world there are a lot of great plugins making git easier.

A lot of the times you have to jump from one changed file to another to do modifications. FzfLua - a generic fuzzy matcher - makes this process very easy. You can fuzzy-find the changed git files, open the necessary one or add all of them to quickfix list and review them one by one: It also helps fuzzy-navigating git worktrees:

Then comes GitSigns. It helps to see the status of each line (appended, removed, changed), quickly view the diff of the current hunk, navigate between hunks, undo hunks, stage/unstage hunks, etc:

Both FzfLua and LazyGit use Delta to display the diff. They don’t have to worry about making the diff readable - there’s already a good software which does it and does it well, so they just use it.

Then there’s another NeoVim plugin - DiffView - which helps working with diffs and merge conflicts, viewing individual file git history and much more:

🔥🔥 Using NeoVim is an awesome experience 🔥🔥

Using NeoVim Is an Awesome Experience

Sat, 06 Jun 2026 19:36:29 +0000

There are a lot of plugins covering almost anything you’ll need in your development environment.

When there’s no plugin solving your problem, you can manually do it. It’s easy!

For example I wanted IWYU integration in NeoVim and didn’t found any plugins for it. This is how I integrated IWYU in my NeoVim config, and these are the mappings.

I was using a theme plugin which didn’t working with some plugins I was using, on some places didn’t working the way I wanted. I’ve customized the plugin manually and now it works as I like.

The repo was inactive and had a good PR… No problem! I merged the PR directly into my fork.

Sometimes you don’t even need to code anything to solve your problem. I’m using a plugin to manage treesitters. Seems it doesn’t have an “update all” feature and I wanted to update all installed treesitters. In its UI in front of every installed treesitter it shows ✅ and it have “u” mapping to update the “selected” treesitter. To “select” a treesitter you just navigate to its line.

This is what I’ve did: moved the cursor to a ✅ symbol, pressed * and executed this command: :%g//norm u And it updated all of the installed treesitters.

How it worked? Explore the magic yourself 🙂

I use NeoVim primarily for C/C++ development and it have everything I need. And there are NeoVim integrations for almost anything!!

Unity: neovim-unity, nvim-unity.
Unreal Engine: Unreal.nvim, UnrealDev.nvim.
Java: nvim-java, nvim-jdtls.
Android: android-nvim.
Apple ecosystem: xcodebuild.nvim
Dot Net: easy-dotnet.nvim.
CMake: cmake-tools.nvim, universal compiler: compiler.nvim.
Unit tests: neotest
AI: avante.nvim
…

This Is an Example of Why Vim and NeoVim Are Superior to Most of the Other IDEs

Sat, 25 Apr 2026 14:27:34 +0000

I’m writing an article about C++ in markdown (will publish here soon). In that article I have a lot of C++ code blocks and their outputs. The problem I was facing was that every time I wanted to change something in a code block I had to copy the block to a separate C++ file, compile and run to check for errors and update the output in my article.

Of course there are a couple of good plugins that automate this process, but I remembered that I had automated this when I was learning NeoVim internals. I automated this process in neorg files. Neorg is a document type like markdown. It’s a variation of Emacs’ Org mode in NeoVim.

NeoVim uses TreeSitter for syntax highlighting and some other stuff to work with the document structure at the syntax level.

I use a NeoVim plugin which supports highlighting code blocks in markdown files like in the language-native files with TreeSitter. I remember when I was doing web development in other IDEs, before I started using NeoVim, the JavaScript highlighting wasn’t as good in an HTML script tag as in .js files. That’s not the case with NeoVim!

NeoVim gives an interface to work with TreeSitter (and everything).

I wrote a small NeoVim Lua code that extracted the code block under the cursor in neorg files, wrote it to a C++ file, and compiled and ran it in a separate NeoVim window. The same code works for markdown files without any change.

When the cursor is inside a code block, I take the appropriate TreeSitter node and go up through parents until I find the whole translation_unit node. Then I read the translation_unit node’s content which is the entire code block, save it to a file, compile and run in NeoVim.

Now I have to move my cursor inside a code block and press “r” to compile and run that code block instead of copying it to a separate file and doing the job manually.

The idea here isn’t the specific problem I’ve faced and been able to solve. The idea here is that NeoVim gives the ability to do whatever you want without using any plugins.

Maybe other IDEs give that ability too, but who does it in Visual Studio for example, or Xcode (is it even possible in Apple’s ecosystem?).

Everyone using NeoVim does this. Using NeoVim you learn about TreeSitter, LSP, DAP and other stuff and customize your coding environment exactly as you like. You see beyond the green run button.

If someone or even the community has decided that a specific (maybe a little customizable) workflow is the best for most users, it doesn’t mean that it’s the best for you!

Why "Modern" IDEs Are Actually a Step Backward

Fri, 13 Mar 2026 21:18:18 +0000

First of all, when you close your “modern” IDE, then reopen it and open a project, what do you get? An empty editor. It doesn’t recover the old files, layouts, and tabs you had before closing the IDE. Yes, it stores the recent files list, and under the “File” submenu, you have another submenu, “Recent,” from which you can open your recent files.

But after opening an old file, what do you get? Your cursor is at the beginning of the file instead of being at the last position where you edited it. This is absurd. Modern IDEs shouldn’t be this clunky regarding simple yet essential things.

On the other hand, what do you get in Vim or NeoVim? Either you start your config from scratch and add support for this kind of stuff, or you use a preconfigured Vim/NeoVim distribution such as LazyVim, which has already been configured not to act like a dumb piece of brick in these situations. Try to configure your “modern” IDE or edit the source code and recompile it so it doesn’t act like a brick. Good luck :d

Probably you didn’t even notice how easy life can be with the simple intelligence of your development environment, right? Maybe even now you can’t imagine it. You first need to work in a truly professional development environment, then try to go back to “modern” IDEs to understand and feel the difference.

Vim and NeoVim save your cursor locations to registers. These registers are saved in the cache automatically, so after closing and reopening the editor, you don’t lose them. I have a simple autocmd - in the Vim world, this is the equivalent of an event listener - which gets executed every time I open a file, finds my cursor’s last position from the registers, and moves my cursor to that position.

Furthermore, in the Vim world, you can save your session to a file. That session file consists of simple Vim commands which open the saved windows, buffers, and tabs exactly as you saved them. I have autocmds to store the session before closing a project and reload the session after opening a project. To navigate projects, I use a plugin which simply gives me the ability to save a directory list, edit that list, and cd into any of them. Right after the cd, the “project opened autocmd” gets executed. Right before the cd and before exiting Vim, the “project closed autocmd” gets executed. And that plugin supports fuzzy finders such as FzfLua and Telescope.

Furthermore, do you remember the magic of fuzzy searching? FzfLua, a great NeoVim plugin, supports fuzzy searching worktrees of the repo and navigating between them.

I quickly navigate projects and worktrees without losing the state of my editor. When I open a project, every window and every tab is in the same place as I left it, with the same cursor position and the same layout.

Does your IDE allow you to edit the same file in two different splits in different parts at the same time?

More on Fuzzy Matching. Perl Isn't a "Write Only" Language

Wed, 18 Feb 2026 23:29:35 +0000

Some people say Perl is a “write-only” language. Is it? Back in the day, I used the urxvt terminal; it was the best, and every “cool kid” was using it. The de facto window manager was i3 until Suckless took over with its high-quality, simple software like the dwm window manager and the st terminal. The Suckless philosophy is that core functionality should be minimal, with extra features available as patches. You are supposed to patch the code, fix conflicts, and recompile. Even for simple configurations, you edit the source code in plain, understandable C.

urxvt had a great plugin called autocomplete-ALL-the-things. It was a fuzzy matcher for screen text with several modes to autocomplete words, “WORDS” (in the Vim sense), text surrounded by braces and quotes, etc. It worked in the terminal command line, in Vim, or anywhere you typed text. Since urxvt had a Perl interface, the plugin was written in Perl. It highlighted matches on the terminal and allowed you to cycle through them to autocomplete partially typed text.

I was so used to it that working in a terminal without it felt impossible. When I switched from urxvt to st, I decided to port that plugin. I didn’t have an internet connection that day, and LLMs weren’t a thing yet, so I only had man pages and some PDF books. I edited the plugin to act as a standalone CLI tool that took info from stdin and printed matches to stdout. Then I integrated it into st to keep the same experience. This was my very first experience with Perl. The patch is still available here.

Years later, I moved to the Alacritty terminal, which is written in Rust. Since I, the lowly peasant, do not know Rust, I asked the developers to integrate that functionality. They didn’t; they were busy rewriting the world in the most perfect language ever created.

So, I integrated that functionality directly into NeoVim instead. At least there, I have the same amazing tool under my fingers as before. The NeoVim version is available here.

NeoVim uses Lua along with VimScript for configuration. Lua is an easy language, similar to C or even easier. I learned Lua just by configuring NeoVim.

This is the Linux way. We don’t wait for a GUI toggle or a feature request. We aren’t limited by rigid, hardcoded blocks. We patch the source, script the bridge, and build our own reality.

Filesystem Version Control: A Better Way to Manage a Linux System

Tue, 17 Feb 2026 22:21:24 +0000

Have you ever accidentally deleted a folder and lost important data? Or an OS upgrade broke your system and you were forced to reinstall it? Or one of your partitions got full while others still had free space?

When you install a Linux distro, it is not always obvious how much space /home or /root will need in the future. If you choose the wrong size, you have to resize partitions later, which is annoying.

Btrfs solves these problems. With Btrfs, you format your whole drive as a single partition (and a small EFI partition for UEFI). You organize your data in subvolumes. You don’t choose a fixed size for each subvolume - they just take as much space as they need from the drive.

Creating a subvolume is simple: btrfs subvolume create /path/to/subvol

You mount them like regular partitions:

mount /dev/$DISK -o subvol=/path/to/subvol /mount/path

Btrfs also lets you backup data easily with snapshots:

btrfs subvolume snapshot -r /path/to/subvol /path/to/new/snapshot

Initially, these snapshots only copy the metadata, not the actual data. After snapshotting a 100GB subvolume, you might only use ~1KB of extra space. The metadata keeps “pointers” to the blocks of your files. When you update a big file that exists in multiple subvolumes, only the updated blocks get duplicated. This results in very small space usage increase.

If your system breaks, you can replace the broken subvolume with a snapshot of the last working state. You don’t even need a live-USB if you keep a small rescue system - just snapshot your initial system after install and make it bootable. Some tools even allow automated snapshots of the base system and let you boot directly into them.

Another option is ZFS, which is very powerful. It is less common on Linux because of license issues, so it requires more manual work to setup. In fact, Btrfs was created as a result of those licensing issues to give Linux a native filesystem with similar features.

This is how I organize my system with Btrfs.

Fuzzy Matching. This Is Another Powerful Tool Most Vim and NeoVim Users Rely On

Sat, 14 Feb 2026 22:49:12 +0000

In a regular IDE, many users eventually discover the “Ctrl+P” window and use it to fuzzy find files, but that is often where it ends. Or maybe it will fuzzy-match workspace symbols like classes and functions in a single place with files. Meanwhile, somewhere in the menus, a dedicated fuzzy matcher for symbols only is “hidden,” waiting to be discovered some day.

What do typical beginner Vim or NeoVim users do? They google a tutorial on how to configure their editor, watch some videos, and discover a cool feature everyone uses through plugins like Telescope or FzfLua. After installing the plugin, they start configuring mappings and discover an incredible range of functionality. These plugins provide fuzzy matching for search history, command history, document symbols, document diagnostics, workspace symbols and diagnostics, live grep, buffers, themes, LSP incoming/outgoing calls, LSP references, debugger commands, breakpoints, frames, and Vim-specifics like the quickfix list, jumps, marks, registers, options, and many more. And of course, files. Do you know regular expressions? You can match with regular expressions too.

Does this feel like too much to remember? The key is that in the Vim world, your knowledge grows exponentially rather than linearly. It is all about the power of composition. You learn motions, then you learn actions, and suddenly you can combine them. You learn commands and combine those with your motions and actions too. Then come macros: you can record your edits - commands, motions, actions, and all - into a macro and repeat it instantly. Then you discover that just as you can prefix motions with numbers to repeat them, you can do the same with actions and macros. Every new thing you learn doesn’t just add to your skill; it multiplies it.

Remember the undo tree from my previous post? Now we have fuzzy matching and the undo tree together. Since this is the Vim world, software and functionality are not separate, monolithic GUI blocks. You can combine fuzzy matching with the undo tree: your typed string matches against the diff of undo tree nodes, and the matcher gives you separate mappings to jump to that state, copy deletions from the diff, or copy the additions. This is done by combining a fuzzy matcher plugin with Vim’s built-in undo tree functionality.

Can you do this with the GUI blocks of regular IDEs? Who goes beyond GUI configs to edit the source code of a regular IDE and recompile it? In regular IDEs, many users probably never even touch the settings. When you get used to this level of control, you become very fast and waste less mental energy. You stay in the flow state and, as the saying goes, you edit at the speed of thought.

This is a quick showcase of the Telescope plugin.

Undo Isn't Linear. It's a Tree (and Your IDE Hides It)

Sat, 07 Feb 2026 20:42:02 +0000

Have you ever found yourself in this situation: you delete a piece of code, add something new, and then realize you want to bring back a small chunk from what you deleted? You press Ctrl+Z until the deleted code appears, copy it - and then accidentally press some key other than Ctrl+C. Now your newest changes are gone. I suspect many IDE users run into this constantly.

This happens because, in most IDEs, the undo buffer is effectively linear. Or perhaps the UX is so poor that even when the undo history is a tree, most developers never discover it or learn how to navigate it.

In a true undo-tree model, undoing changes and then making a new edit doesn’t overwrite history. Instead, it creates a new branch in the tree. You can then navigate this tree and recover your code from any state it ever passed through during editing.

Combine this with persistent undo buffers - where closing a file, restarting the IDE, or even overwriting the file with an external tool doesn’t destroy your undo history - and once you get used to it, coding without this feature feels like zipping your code and uploading it to Drive instead of using Git.

Now consider this: what happens when you close a file in your IDE, or close the entire IDE, and then reopen it? Usually, the file opens at the beginning. In Vim or Neovim, with just three lines of configuration, the file reopens at the exact cursor position where you left off. You can even restore the entire layout of tabs and windows.

This is why Vim and Neovim are better - not simply because they have an undo tree built in, but because almost every Vim user knows about powerful features like these and actually uses them. I’d bet that very few “regular” IDE users use comparable features, or even know they exist - or ever imagined that editing could work this way.

Vim and Neovim aren’t black boxes from the ’80s. They support LSPs (thanks, Microsoft 😄), DAP, TreeSitter based syntax-aware highlighting and textobjects, excellent AI integration, and all the classic Vim advantages: marks, registers (clipboards on steroids), macros, and more.

You have to try it. If you think you don’t have time to learn Vim, the truth is you don’t have time not to. Vim saves an enormous amount of time - and makes coding a better and more fun process.