G2

Luca P.

Chief Operations Officer DEQUA Studio | Formerly CTO in MarTech

Marketing and Advertising

Mid-Market (51-1000 emp.)

6/18/2026

"Vim’s Composable Editing Language Delivers Speed, Reliability, and Remote-Friendly Power"

5/5

What do you like best about Vim?

The reason Vim has outlasted every other editor in my workflow is that the editing model is a language, not a set of buttons. Commands compose: an operator plus a motion, so ciw changes a word, dt) deletes up to the next paren, yi" yanks whatever sits inside the quotes. Once that grammar is in your hands you stop thinking about keystrokes and start thinking about edits, and the speed that comes from that is hard to give back once you have it. The fact that some flavor of vi sits on essentially every Unix and Linux box is the other half of why it stuck. I SSH into a server I have never seen before and Vim is already there, behaving the way it does on my own laptop, which means the muscle memory I built once keeps paying off on machines I do not control and cannot install anything on.

It starts instantly and it stays out of the way. I type vim and a file name and I am editing before a heavier tool would have finished drawing its window. It barely touches memory, which matters on the tired jump boxes and cramped containers that always end up being the thing you have to work from, and it opens files that make graphical editors stall. Tailing a multi gigabyte log to find what just blew up is a normal Tuesday, and Vim loads enough of it to be useful without falling over. It is not a flashy tool. Dependable is the word I want for it, and it has earned that over years of not letting me down at the wrong moment.

The search and replace engine is the feature I would miss most in day to day work. The full regex syntax behind :%s means a rename or a reformat across a file is one line, and ranges let me scope it to exactly the block I care about instead of the whole buffer. The global command, :g/pattern/ followed by another command, is the part people underrate. I use it to run an edit on every line that matches a pattern and leave the rest untouched, which turns a tedious manual pass into a single instruction. Macros cover the cases too irregular for a substitution: record once with q, replay with @, and a fiddly repeated change across two hundred lines is finished in a handful of keystrokes. This is the point where the editor stops being a text box and becomes a small automation tool I keep in my hands.

Diff mode is the piece that quietly justifies keeping Vim set as my git mergetool. It lines up two, three, or four versions of a file with the differences highlighted, and :diffget and :diffput move changes between them without me hand copying anything across. Resolving a merge conflict during an SSH session, on a box where no graphical merge tool exists, used to be the kind of thing that made me want to get back to my own machine first. Now it happens in place, in the same window I was already working in, with the same keys I use for everything else.

Because it needs nothing more than a text connection, Vim fits the way I actually work rather than fighting it. It runs inside tmux, survives a dropped link when the session is held open on the far end, and behaves identically whether I am at my desk or three hops deep behind a bastion on a high latency link. Remote desktop and GUI editors are miserable on a bad connection. A terminal and a keyboard are all this asks for, and on the days things are going wrong that is usually all I have to work with.

Customization is real, with the honest caveat that you are the one doing the building. My .vimrc is a single file in a git repo, so a new machine goes from a stock install to my full setup in about a minute: clone, symlink, done. The split windows (:sp and :vsp), the buffer list, the named registers, and the quickfix list for driving edits off a grep are the parts of that setup I lean on hardest, and once they are wired the way I think, the daily experience is fast and quiet. Plugins extend it further through native package loading or a manager like vim-plug, though that is a project you maintain over time rather than a store you shop in once.

The newer Vim9 scripting dialect is a genuine step up, and I say that as someone who wrote plenty of the old vimscript and never enjoyed a minute of it. Config and plugins written in it load noticeably faster and read more like a conventional language, with proper scoping and closures instead of the quirks that made the legacy version a chore to debug. And the whole thing is free and open source, with no account to create, no telemetry phoning home, and nothing nudging me toward a pro tier. The licensing even routes donations toward children's charity work, which is a pleasant thing to know about a tool I run all day. The community maintaining it now is clearly committed to keeping it alive, and that counts for something when you are building a long term habit around a piece of software. Review collected by and hosted on G2.com.

What do you dislike about Vim?

The real cost of Vim is the first few weeks, and it is steep. The modal model that makes it fast later makes it baffling at the start, and I have watched new teammates get stuck trying to do something as basic as quit the thing. There is no discovering it by clicking around, because there is almost nothing to click. What works is starting people on vimtutor, handing them a deliberately minimal config so they are not also fighting a wall of plugins, and sitting with them through the first setup so the early friction lands on someone who can answer "why did it just do that." The investment pays back well, but it is heavily front loaded and there is no honest way around that.

Out of the box, Vim is a text editor and not an IDE, and turning it into one is squarely on you. There is no built in language server support and no Tree-sitter, so the features a modern editor ships with by default, go to definition, completion that actually understands your code, rename across a project, all arrive through third party plugins. The usual routes are coc.nvim, which works well but drags in a Node runtime you then have to keep installed and updated, the Vim9 LSP plugin, or ALE, and the configuration styles between them do not line up, so moving from one to another means relearning the wiring from scratch. My standing advice to my own team is to pick one stack, put it in the shared dotfiles, and stop there, because the choice paralysis costs more than the setup does. It is still more assembly than an editor that simply includes this, and on a heavy codebase you feel that difference daily.

A papercut that bites at exactly the wrong moment is clipboard handling, which depends on how the binary was compiled. On a stripped down server build without the right flag, the system clipboard register does not work at all, so a yank stays trapped inside Vim and never reaches the OS clipboard. The first time it catches you, you are switching to your browser wondering why paste is empty. Checking the build with a quick version query tells you whether the support is even there, and installing a fuller package usually fixes it, but it is an odd inconsistency for a tool that is otherwise so reliably the same from one machine to the next.

The last thing worth naming is the direction the ecosystem is drifting. A lot of the newest plugin work is being written for the fork rather than for Vim, so some of the more experimental tooling shows up there first and lands later, or sometimes never, on the side I use. The mature plugin set still covers everything I need for actual work, and the gap is not a practical problem today, but it is a trend, and if your appetite runs toward the bleeding edge of editor tooling you will feel it pulling the other way. Review collected by and hosted on G2.com.

What problems is Vim solving and how is that benefiting you?

The core thing it solves is editing files on machines that are not mine without hauling tooling onto them. Before I settled on Vim, touching a config on a remote box meant either copying the file down, editing it locally, and copying it back, or wrestling with whatever happened to be installed on the far end. Now the editor is already there, I make the change in place, and the job is done. The benefit is less about raw speed and more about not having to think about the editor at all when something is broken and the clock is running against me.

Consistency across a messy fleet is the next one it handles. I work across my own laptop, throwaway containers, customer boxes where I have limited rights, and the occasional appliance, and the editing experience is the same on all of them. The keys do not change, the commands do not change, and the config I carry behaves the same wherever it lands. My attention goes to the problem in front of me instead of relearning a tool per environment, and that saved friction is the kind of thing you only notice when it is gone.

Reshaping text in bulk is a problem it handles far better than the alternatives I used to reach for. Restructuring a config file, munging a log into something readable, or applying the same fiddly change across a whole file used to mean either hand editing line by line or dropping to a stream editor and trusting a regex I could not see the effect of until after it ran. Doing it inside the buffer, with the global command and macros, lets me watch each change happen and stop the instant something looks wrong. The edits come out both faster and safer because I am no longer working blind and hoping.

Merge conflict resolution stopped being tied to a graphical tool because of diff mode. A three way conflict in the middle of a deploy used to send me back to a machine with a proper merge UI before I could sort it out at all. Wired in as the git mergetool, Vim lets me resolve the conflict in the same terminal session where I hit it, which keeps me inside the flow of whatever I was shipping instead of breaking it to go find better tooling somewhere else.

Working over poor connections is a problem it removes rather than just softens. On a high latency VPN, a flaky client link, or a session I need to survive a disconnect, a text only editor running inside tmux simply keeps working where a graphical setup would crawl or drop the connection. Before, a bad link made remote access painful enough that I would quietly put the task off until I was back on my own network. Now the quality of the connection barely registers, because the tool was built for precisely this situation.

Carrying a working setup between machines is the last benefit, and it covers the awkward case of a box I cannot install much on. My configuration lives in a dotfiles repo, so getting productive on a fresh machine is a clone and a symlink, and even on the occasions I cannot bring my full setup, the base editor is already present and already familiar. Onboarding myself into a new environment, or being useful on a borrowed laptop in a hurry, both got shorter because the thing I depend on is either one command away or sitting there waiting for me. Review collected by and hosted on G2.com.