- the main value of vi is editing speed. It’s just much more efficient to edit text this way. Have you ever realized you needed to make a bunch of changes to a file and then sort of groaned at how much legwork that will be? Maybe you even don’t bother because it doesn’t seem worth it? vi usually makes short work of these. It’s hard for me to overstate how big of a productivity impact this has had for me: it makes sure the mechanics are never the bottleneck in my coding process. The editor can keep up with me.
- the most common painpoint with vi is that you don’t get all these snazzy IDE features. That’s why sometimes people run IDEs with vi keybindings which are never quite exact; they want features like language-aware renames and other refactoring support that vi lacks, so they make a tradeoff. But this is actually improving rapidly, thanks to the proliferation of language servers and their rapidly improving support in Neovim. I hope that soon I will no longer have to think about these tradeoffs.
At any rate, everyone should write code in whatever tool they like most, but that’s been my experience with it.
If it is purely mechanical type changes I would just use sed or find and replace, otherwise I think scrolling with a mouse and clicking tends to be fast enough. Could you explain a bit more about how it could be faster?
Probably best to see it in action to fully appreciate it.
But it really is a lot of faster. I've watched colleagues edit code with the mouse (e.g. move this "if" block under that "else" clause or what have you) and I will say it's much, much slower than I would do in vi. They are not incompetent or clumsy; I would have been slow with the mouse too. In fact, I'm editing this comment with a keyboard and trackpad and it feels awkward and slow.
Here are a few ways in which these actions just happens faster vi:
1. jumping around in the file using your keyboard. Taking your hand off the keyboard, moving the mouse to the right spot, clicking there, putting your hands on the keyboard, and then typing is a lot of movement. In vi, you have lots of tools to just move around, i.e. to do the part you do with the mouse. You have incremental search, bookmarks, jumplists, keys for jumping to the delimiter match, or the next code block, or jumping to a line number or function definition. There are EasyMotion-style plugins that let you jump quickly to whatever you're looking at on the screen. And many more. These are all optimized to be just a couple keystrokes away. They take time to learn and become fluid with but they give you a kind of total, effortless control over what part of the file you are editing.
2. Just good keyboard-centric editing basics. Putting aside all the ways you can move around a file (or files!) and all the ways you can repeat similar actions in different parts of the file, you also just get to be quicker making specific edits. You can _probably_ do all of this with readline-style keyboard shortcuts in other editors (e.g. replace this word with another word without double-cliking it with a mouse), but vi forms a sort of interactive language for doing these edits, and the way vi works just causes you to learn them and use them consistently.
3. Fine-grained control of editing actions. This is the hardest one to explain. Modal editing has the property that your actions are sort of transactions. You are in normal mode, you take some action that puts you in edit mode, you do some typing, and then you leave edit mode and the thing you did is now a block of action. It can be undone as a block and applied again elsewhere as a block. So for example, if I want to replace "}," with ");" on like four lines, I can do that by doing it once and applying it three more times to each line (using "."). Sure, you could also do that with a find-and-replace tool, but just operating that menu isn't worth the overhead for four lines. In vi, that's just how you edit; it's by-the-by, with no special effort required.
4. For more complex repeatable actions, you have macros (which is sort of like a second-level of text editing transaction), vi's strong regex support, actions that work on rectangular selections, and plugins for multiple cursors. One way to think about the sed case is: what if you didn't have to reach for another tool and it was instead sort of conceptually integrated into your everyday editing experience? It would be much lower friction to reach for, so you'd use it more and more efficiently.
There's more, but I think that's the important ones, or at least the ones I think have given me the most mileage. It's all easier to show than tell, and of course YMMV.
There's no way you're going to appreciate the power of either editor after using it only a few times.
Every time I (re)turn to a language or other text-based thing, I could very easily (and often do) get sucked into a tinker-thon trying to perfect my vim experience.
I've had to accept that I just have to use the IDE du jour (or de la majorite, more accurately) to get up and running. Though you bet I'll lose some evenings to getting a vim setup working.
Need I say anything more?
You bolt literate programming onto it.
Then you tell your code blocks they can send input and output to each other via text in the document. Now you've got an excruciatingly well documented multi-language pipeline.
Then you get the source data for all your analyses in real time from [wherever they came from].
Then you render it _beautifully_ with your dependency graph documentation generated from graphviz (which graph data was newly inferred on this very run).
My first org-mode killer app, years and years ago was a monthly billing collection and analysis for a backup system I was running. The first pass took me a week to figure out how to collect and analyze. A few iterations later it was literally open the org-mode document and tell it "Do the thing". All my intermediate work was shown, everything was clear and open to inspection, and beautifully typeset. And I could generate it as HTML if they wanted it in a web page. (at the time they wanted PDF).
This is one of the ways org-mode is great. There are others. :)
It's primarily two things:
1. A markup syntax
2. a TODO manager. It's flexible enough that you can come up with your own custom TODO workflows (e.g. GTD, etc). You can do queries on a fair amount of metadata to construct your TODO list.
In support of all that, it has good table features (you can do spreadsheet like functionality in them), code management (execute source code blocks similar to Jupyter, but you can have code in multiple languages communicate with one other), link to just about anything (with a bit of setup, I can even link to Outlook emails). While in the middle of your work, you can capture notes and/or TODOs and have them filed away in the appropriate file and location within that file.[1] Finally, you can export into many formats (I don't write pure LaTeX any more - I always export an org file to LaTeX).
Example of a simple thing I do.
I read an email. It contains actionable information. With a keystroke, I create a TODO item in org mode, which contains a link to the email. Later when browsing my TODOs, I have access to the context.
Likewise, I'm reading an article in Chrome/Firefox, and I want to file it away for some reason. With a click on a bookmarklet, it sends the URL and related info to Org mode in Emacs and it is filed away.
A more sophisticated example that required some elisp: I take meeting minutes at work. Any time something comes up where a TODO is assigned to a person, I hit a keystroke and type in the TODO. It finds the heading called "Action Items" for that particular meeting and files it there. At the end of the meeting, I export the minutes into HTML or Word and email it out.