For those who do not understand why people are fanatical about vi, here
are some reasons:
Vi is keyboard only. This means that actions with the mouse are optimized through the keyboard. There are "hotkeys" for most
tasks you use with a mouse.
Vi has the idea of objects. Words, lines and paragraphs are objects you
can operate on.
Vi defines a "language" for operating on objects. For instance, 'd' is
delete. You can delete a word using 'dw'. You can delete 5 words with
'5dw'. Another example: deleting a line is 'dd'. Delete 5 lines with '5dd'
It is a modal editor. At a basic level there is an "edit" (insert) mode,
a "navigation" (normal) mode, and a "selection" (visual) mode. The power
of a modal environment means that commands and hotkeys now have a context
and do slightly different things in different modes. While this may be
overwhelming, once all these modes are ingrained in you, it allows you to
be extremely efficient since you do not have to remember new hotkeys. For
example, in the navigation mode, you can apply the 5dd to delete 5 lines.
In selection mode, use '5w' to select five words. 'd' now deletes
everything in the selection. If you've ever struggled to manage and
remember your hotkeys, modal environment is your friend. (set this up in
mac using something like hammerspoon.)
It includes some really nice out of the box features: Macro system to save
you time with repetitive tasks, regular expressions search and replace,
time travel through your edits, it stores your edits in a tree so you can
navigate to your changes even after multiple undo/redo. "." repeats the last change. You can also apply a number before it to
repeat the change n number of times. I am surprised how often I use this
that this is and this is first thing I miss when using another editor.
Vi is worth learning as it will improve your productivity. This is
especially important if you have to edit a file on a remote server. Vi is
installed on every unix distribution. Many cli tools and shells have a vi
mode. This allows you to take the vi 'language' to all these cli tools for
more productivity.
For those who struggle to learn, I highly recommend Vim Adventures. After
that, force yourself to use vi for your every day edits and it'll be
second nature in a couple of weeks.
vi also builds its concepts together in a great way. Navigation keys are powerful, but combined with actions, they become monumentally powerful in a way few IDEs seem to replicate well. Something simple like "copy the next 10 lines to the clipboard" is just 10yj or 10Y or even y10j. No awkward reaching for control keys. Now combine those actions into macros and things get really fun.
One of the most fun navigation keys is the under-reported "f" key. If the cursor isn't where you want it to be, you can easily put it on the right line (perhaps with 55G or something if you want line 55) and then to move the cursor over the character you are actually looking at you just type f( assuming that ( is the character you want the cursor on. It's just great... it's about having the computer work around your human experience of looking at the screen in a nice way.
> One of the most fun navigation keys is the under-reported "f" key. If the cursor isn't where you want it to be
There's also the t key which will place the cursor on the character just before it. There are also the F and T keys that will search backward in the same line and the ; and , keys that allow you jump from character to character in that line.
But, if you want more flexibility and the ability to jump across multiple lines, a / or ? search will allow you to select text up to and including the multiple characters you search for.
There are so many navigation keys and combinations, that's kind of what is great about it. A lifetime's worth, in the case of vim and neovim. I personally have got a lot of mileage out of f, F, t, T, /, ?, G, 0, W, w, e, E, b, B, }, and %.
Unfortunately, the barrier I faced with even trying VI is that you cannot discover any functionality intuitively. Exaggerating (but just a little) I could not even figure out how to type without someone giving me a tutorial. That was enough to make me stop.
I agree. You need to use vimtutor to get the basics: the simplest modes (insert, normal), the simplest normal-mode motions (hjkl), the simplest normal-mode actions (d, c, f/t), and the concept of "adverbs" (8j, 4dw, 2df]).
Once you have mastered these simple concepts, most of the magic comes from (1) combining them (2) googling the things that you intuitively know must be possible, and discovering how they're done, which in turn gives you more basic concepts.
At that point, your feedback loop gives you escape velocity, and you'll never willingly go back to a standard text editor again. :)
For me, learning came when I was on an IBM RT/PC (pre RS-6000), in something like 90 or 91. I used IBM's editor from the console, but one time I had to edit something from a terminal back in the shop. Which didn't have full support for the IBM editor (Ined I think it was called), due to the way the keyboard was mapped. Something about left cursor was the same as backspace (ctrl-h).
Well, that did it -- I went back to my desk, and pulled up vi-tutor.txt, then never looked back.
When given a tradeoff between intuitivity and other benefits, vi almost always breaks against intuitivity. It's this design philosophy taken to its logical extreme.
I understand the frustration since even as a veteran users of Vim, there are lots I do not know about.
Vi is a completely different way of thinking. I would compare it to learning to program. When you first start, there isn't very much that is discoverable. You just have to sit through the learning. Once you do, you have access to a lot of power.
I have switched to doing most of my work on IDEs like IntelliJ, VSCode, etc and the first plugin I always install is vim keybindings. It makes editing and navigating much better.
I've always thought that doing 5dd and such was a bad demonstration of Vi(m) since I never know how many lines to delete. I'll just dd multiple times. More powerful vim commands are like daw (delete all of a paragraph), di) (delete inside of a set of parentheses), and dtX (delete until the character X).
daw deletes the word you are in (delete a word). But dap deletes a paragraph. And you can tell vi what you mean by "word" and "paragraph" (I think) in your settings file.
I tried this for a while but it never clicked for me. I prefer using semantically-meaningful groupings like paragraphs or parentheses, it just seems nicer. And relative line numbers wouldn't make, say, 5dw any easier to count.
You can use: df<char> to delete forward (including char),
dt<char> to delete forward until char. (excluding char)
d/<search><Enter> to delete until search pattern is found
In case you wish to type immediately after deleting, replace 'd' with 'c' in the above.
I've been coding for a bit more than two years, then I decided to finally learn vim.
I honestly don't know how I did before, it's just so satisfying!
It's not even as hard as they say.
+1 for vim adventure, definitely great learning ressources!
>> Vi defines a "language" for operating on objects.
And the objects are text-centric (word, sentence, etc). Add on top of that a powerful macro system, and you get a really powerful tool for text manipulation.
Now imagine that SSH going from a Citrix windows desktop running on a Windows 10 VM on your linux laptop. Every key press reacts in around a second. Welcome to banking "security"!
Now let's say I want to `d5}`, to delete the next 5 paraghraph. In vi(m) I can do this by telling it "hey vim, delete those 5 damn paragraph!"
In fancy VScode I have to say more like... "Hey editor, wait a sec, I'm moving my cursor over there and select a couple lines which happens to be 5 paragrahs, OOOPS, I went a bit too far, now let's go back. YES, now delete them!".
Other examples:
- "increment this number by 5"
- "delete this html tag recursively"
- "indent the next 20 lines"
- "remove all the arguments from this function call"
- etc.
Vim has a language, _that_ is the powerful part.
To be fair, thankfully VSCode (and any of the other fancy IDEs) have basic vim-functionality providing plugins.
> Now imagine that SSH going from a Citrix windows desktop running on a Windows 10 VM on your linux laptop. Every key press reacts in around a second. Welcome to banking "security"!
Unfortunately this is some external requirement I cannot do anything about. Also, as opposed to many people, I actually got to work and know both the IDE-world (including VScode), and the vim world. I have a base for comparison.
There are also times when the available bandwidth is limited, so just having to use fewer keystrokes to edit a file speeds up the process. I was able to connect to remote linux servers over dial-up and edit files on those servers with vim without issue. Editing and saving over ssh was more of a hassle since it took longer to save the file (and I save pretty often).
Anyway, unfortunately given setup won't even be viable with anything running "local", since in the mentioned citrix environment we cannot install anything, so no vscode, no local vim, no nothing...
Something that I always find lacking in these discussions is that the VIM evangelists never mention the way that I use vim: strictly as a keyboard-only editor plugin.
I tried using vim-only setups but there's so much configuring and weird things. Nothing to me has worked as great as my current VSCode + Vim plugin setup. It's the best of both worlds, as I get the quite frankly absurd speed improvements of VIM while also the great user-friendliness and ease of VScode
VSCode is great and has a lot of advantages. I still use vim in a terminal because of tmux. Unfortunately that means I have to give up some of vscode's advantages.
I'd love to hear more about this. What VS Code plugin are you using to accomplish edits over SSH? I checked out Remote Development, but it is actively unable to function with the open-source version of VSCode:
> This may have been true a decade ago, but editors like Visual studio code now have remote editing abilities over SSH.
VS Code and vi have different use cases. Contrary to what you said, most people are not going to open VS Code to make a quick edit to a config file. If that works for you, fine, but the overhead of starting electron is significant.
You are right that it is not as necessary as before but there are still plenty of times where vi was still the faster option. Since Vi is so lightweight, opening large files remotely might be useful vs vscode remote ssh.
What I observe is that most vim fans who swear by it use it as a bare bones editor, syntax highlighting at most. No auto-completion, go to definition or any other IDE stuff. Yes, it is possible to make vim IDE-like but very few do so.
The existence of "modes" is also opposite to the approach which is know for decades to be less prone to accidental errors: having no modes and always being able to perform more undo steps.
There were even the games of considering what plain text typed in wrong mode would cause the most of the damage.
The main reason Vim and Emacs have their current followers is that the competing editors on Linux or Unix platforms are significantly worse (on average), not that these two are by any means any kind of the possible optimum. And boy, is the competition worse.
(Personally, I use console editors only if I have to, and then prefer to use vim, but otherwise I prefer my customized low-footprint programmable GUI.)
> The existence of "modes" is also opposite to the approach which is know for decades to be less prone to accidental errors: having no modes and always being able to perform more undo steps.
vim has had the multi-level undo and redo for a number of years. If I really screw up, I can always run something like :earlier 5m to get back to the state I was at 5 minutes ago.
The only problem I have with some of the normal mode keystrokes is when I want to use some of the window based shortcuts and accidently press ctrl-w while my browser window is open (which closes the tab) :)
I used to be like you describe, mostly because language-specific plugins were a dumpsterfire of hidden complexity, that really slowed down your editing experience.
While some plugins are brilliantly-designed, it takes a long time to learn how to configure one language plugin to your tastes, and that learning is generally non-transferable to other language plugins. (vim-go fits this to the T, ime).
https://github.com/dense-analysis/ale (along with the language-server movement in general) changed my perspective. I now do at least the go-to and autocomplete half of IDE things, now.
I know some people at work use it, but I haven’t gotten around to trying it. What’s the advantage over using ale to compose gopls or python-language-server? Is it the fancy windows? :)
I took a cursory look at their repo. I might be understanding this incorrectly, but it looks like you have to run node as a sidecar to use it? Isn’t that really intensive vs ALE? I figure if I wanted to run V8, one might as well use VSC, which after all is an electron app. :)
Let's not forget Bram Moolenaar, who also deserves credit for extending the work on Vi. Vim [Vi iMproved] is likely (along with NeoVim) the actual Vi editor most people are using these days.
What's the story with NeoVim exactly? I am trying it out on Linux because I got some recommendations that it's better than Vim, but I've run into some problems because for instance with setting up plugins and things, lots of times the documentation seems to be geared toward Vim, and sometimes I've gotten errors it's hard to figure out because of this.
It kind of gives me the perception there just aren't that many people using it, so it might be one of those tools which is technically better but doesn't have the critical mass of community to really be useful.
Am I off base there? I mean what are the tangible, user-facing advantages of NeoVim over Vim?
This is in some part due to the fact that neovim has been on Github longer, but it's still a a major indicator.
Neovim has many benefits over Vim, and has been applying pressure on Vim for years to improve its own development and codebase. Nvim has first class support for Lua outside of Vimscript, which has enabled a lot of people to write more powerful plugins. A lot of NVim's featureset has been copied into Vim over the years (one of my favorites is the hover window, which has allowed IDE like support for code references/comments/source). Supposedly, Nvim's codebase is significantly easier to maintain and contribute to, due to the nature of having a community of contributors that built it from ground up, as opposed to one primary developer working on Vim.
The parity has reduced over the years, but Nvim has been significantly ahead in pushing new features and active development over Vim resting on its laurels.
Why does it have a cult following? Because there are enough people to keep the project going and it makes them happy for whatever reason.
Why does it have far less usage than Vim proper? Because it's a young, niche project, and Vim has been around forever. Same reason CentOS and Ubuntu have a far bigger usage share than any of the "trendy" distros.
> Neovim definitely has significant market share, you can compare Github stars as one statistic to consider:
I would not consider GH stars to be at all indicative of market share in this case. Vim is installed by default on so many distributions that people just use it and expect it to be there. I have been using vim for at least 15 years and I didn't even know its source was hosted on GH until seeing your post. NeoVim, on the other hand, is something that you have to know about and seek out, and in doing so it's pretty likely that you end up on its GH project page, making it more likely you'd star it.
Yeah, it's not an accurate indicator since various factors play into how many stars Neovim has, e.g. Vim is prebuilt into most OS distros, so lack of a need to download it, Neovim is more contributor friendly, etc. I highlighted this not to show the insignificance of Vim, but rather the rise of Neovim.
NeoVim certainly got a lot of press for a while. I think it has faded quite a bit in the past few years since Bram stole their thunder somewhat by integrating their biggest selling points.
I am fairly certain I have NeoVim starred on Github. I haven't used the editor except for an hour to try it out when it was new. I use Vim all day every day for work.
I would expect a similar situation for many of those stars.
> I mean what are the tangible, user-facing advantages of NeoVim over Vim?
Hard to answer really. I mean, what are the tangible, user-facing advantages of having llvm/clang over only having gcc? of libressl over openssl? Chances are you aren't targeting libclang in your code so does it really matter if it exists, from a user-facing perspective?
I recall neovim started like many projects, because some folks wanted to add stuff, clean up, change directions slightly, etc, and the current project at the time basically didn't want to do it. Consider that at some point in the past a person probably asked the same question you are asking, except about vim vs vi.
Not 100% sure but neovim added several feature first: a better cross-platform input method (libuv); asynchronous plug-ins; a terminal emulator; probably others - and some of these features have bled into vim. Essentially, pressure and feature competition from neovim has improved vim. Neovim has done a bunch of other cleanup; as far as user-facing advantages it would mostly come down to better plug-in architecture and possibly better plug-ins.
NeoVim was started to add in a couple features that had gotten pushback from Bram when the original forker(?) (long since moved on from the project) got frustrated with getting shot down.
Basically the relationship at this point between the two projects appears to be that the NeoVim team implements some features. The ones that gain significant traction, Bram then implements in his own style.
At this point they are basically at feature parity with each other I think. The main difference between the two in my experience is that NeoVim is much more likely to integrate existing libraries, while Vim is more of a self-contained project.
One of the side effects of that is the NeoVim people like to brag how much code they've deleted from Vim. The thing they don't mention is all the deps they've added in the process.
> One of the side effects of that is the NeoVim people like to brag how much code they've deleted from Vim. The thing they don't mention is all the deps they've added in the process.
You present this in a negative light, and perhaps it's misleading of them to not acknowledge the added dependencies, but this is exactly what I want maintainers of my workhorse software to do. I would much rather they delete their own code and replace it with well-tested, robust dependencies rather than maintaining their wheel reinventions.
(Of course, whether or not the chosen dependencies are well-tested and robust is the trick.)
What made me adopt it a while back was the work they put into the plugin system. I honestly don’t remember the technical details (better or real async maybe?)
But the end result for me was being able to use things like deoplete without the editor pausing on me or missing keystrokes.
My guess is these days bringing a newer vim with you vs relying on your distro’s probably has the same benefits. I only use plugins locally and haven’t bothered switching back.
Thank you. I am sitting my baby on my arm was to lazy to type that. When both of this features stabilize I think they will sufficiently set NVim appart from Vim and make it its own personality.
Besides Lua as an alternative scripting language there currently is no compeling reason to switch over.
This is so often the case with long-running projects. People forget that the much of the work that went into the current product wasn't necessarily done by the original author. Everyone knows git is Linus Torvalds. But Torvalds constantly states that Junio Hamano deserves a lot the credit for making it the tool it is today. It sounds like a similar situation with vim.
+1 and all the plugin authors for writing and maintaining plugins. I find Vim/NeoVim so good for working with JavaScript and Go thanks to it's design and ecosystem.
It's a favorite pet peeve of mine (and very well represented in this thread) that people call it vi when they actually mean vim. I believe on some systems vi eventually became an alias for vim which is how all of this started.
Most folks would be very much irritated if they actually had to use vi because of some crucial features missing.
"Among Joy's list of achievements are BSD Unix, NFS, UltraSPARC designs and some work on Java" - not to mention Berkley Sockets. But his greatest gift to man was vi? I think not!
Full disclosure: I'm an "emacs guy" but I don't care about the silly old emacs/vi wars. I would just say as awesome as people find vi to be, it's among the least of Bill's accomplishments. That's how awesome he is!
I don't know how much he was involved in the "3M" model that Sun pushed, but that was pretty big too: 1 Megabyte of memory, 1 megapixels on the screen, 1 Megabyte/sec network connection. All seems like nothing now, but at the time of the early Sun workstations, that was the definition of a high end machine.
I think more people should shoot for something like that.
I remember when tesla first created it's electric cars and they put these huge expensive batteries in them.
Other cars required an engineering degree to figure out how to get across town and back, and tesla had these cars that freed up your mind and let you drive. and then they could build on that with the supercharger network.
Eventually the range went up and the battery cost went down and the future was the present.
Vi is the ultimate example of software that is "easy to use" as opposed to "easy to learn", it is great that we still have Vi and so many other unix tools that use the same philosophy.
One of the biggest things that has happened to computer software in modern times is the balance between "easy to use" and "easy to learn" has shifted dramatically towards "easy to learn".
There is some software that can achieve both at the same time but IMO much of the time the two ideas are counterbalanced against each other with each hurting the other.
Before the mouse almost all software was harder to learn but users would become extremely fast & efficient when they learned to use it. Vi is a classic example. So were lots of applications that had character cell user interfaces and function keys & shortcuts for everything.
A lot of mobile stuff is the ultimate opposite.. it takes 2nds to learn but you're never going to be able to use it any more efficiently or quickly than you did 5 minutes after you first tried it.
I agree. While vi has an unusually steep learning curve among software, I think of it sometimes when I design user interfaces. Design with the 2-week user in mind, not the first-time user.
What I would call fraidy-cat designers work themselves into a tizzy asking themselves, yes, but will users like it or understand it the first time they see it? I encourage people to instead be a bit bold and ask, will the user grow to like it after using it for a week or two?
There are three kinds of software:
1. Easy at first, and mediocre for the rest of your life.
2. Takes some getting used to at first, and awkward for the rest of your life.
3. Takes some getting used to at first, and wonderful for the rest of your life.
I suppose there might be tools that are easy at first and wonderful for the rest of your life, but they are rare. Most classic tools are in the last category. And it's not just software. An audio engineer probably took a long time to learn how to use a mixing board, but now it's second nature. Manual focus on a professional camera, also something that's hard at first but effortless and even preferred after practice.
The thing is, if you optimize for the first-time user, you might be blocking yourself from making something really powerful and simple, though at first strange. Some of the best things in life are at first strange.
In case someone is still trying to read my post in bad faith, of course you should not make it harder than necessary for first-time users. Designing interfaces is hard work. This is not an excuse to be lazy. It is an invitation to make your software as good as possible for long-term users.
fwiw, I totally agree with everything you've written, and take it in good faith.
I've heard the words "power tool" and "platform" used to describe what you're talking about. The best tools have a simple core with many silos, but those silos are highly-configurable and composable. You can call it UNIX-philosophy, but it's evidently existed in other domains (carpentry, baking, "interchangeable parts" in manufacturing) for a very long time.
I don't think there's a lot of software written this way. Vi, Excel, UNIX pipes, functional programming languages, regular expressions, GNU ledger, Redis come to mind.
Not a lot of consumer software fits this description, that I can think of.
the plan9 port API is based on sockets, yes - because plan9port is a port of plan9 runtime to other OSes.
However, BSD Sockets are bad API, and can be argued to be one of the reasons, if not major reason, behind many issues in IP-based networks, including slow IPv6 rollout.
They also were a rushed port/rewrite of existing TCP/IP code done essentially by grad students on a grant from DoD because vendor (DEC) told DoD that they are not getting any new models of the computer they used primarily for TPC/IP.
Part of the requirements was that the resulting code is shared so that vendors could quickly provide support for TCP/IP in various products.
My career as a software developer is indebted to vi.
text editing can be a thankless, soul-sucking chore without the proper tools. I've seen otherwise intelligent individuals abandon a software career because they never quite figured out how to efficiently do it. I wouldn't say that vi/vim is the only tool that can do the job, but it's the one that I've chosen.
I was introduced to vi by a stroke of fate. My buddy in college pulled me aside and introduced it to me. I initially thought he we crazy because we had no shortage of schoolwork to do and vi just seemed impenetrably nuts. Really glad he did: my career might have taken a very different arc without that encounter.
vi has been life changing. Learning vi altered my entire concept of what interacting with text could be, and even my personal physical relationship with a keyboard. Using vi is like driving a stick shift; satisfying in the depth of control once the learning curve is done. vi has been a daily friend now for over 20 years. So much insight is cooked into those little key mappings.
It's not about doing it without a mouse, it's about doing it fast, comfortably, and powerfully. Pointers are a useful addition to graphic capable vi implementations, but if you do everything with mouse or trackpad movements then I don't think you can claim the zen of vi.
My fascination is that the original motions were not invented to escape the imprecision of graphical pointers, even though that's their main selling point today. They were invented to minimize (1) excessive tty printing, because printing is slow (2) keystrokes.
That, in 2020, these optimizations made in 1960 allow you to avoid the imprecision and slowness of a graphic pointer, we get for free :)
I used Emacs for 5 years before learning vi. What a change! While Emacs tries to put the kitchen sink inside the editor, vi tries simply to be a keyboard interface to the rest of the system. I've never looked back since I learned this way of working.
Emacs user here. Emacs' real value is not really in text editing, though it is no slouch in text editing. It does so many other things so well, at this point it is unthinkable for me to not have it.
Eg. OrgMode, Magit, Helm, Tramp, Dired and slime to mention a few. Its a lifestyle ;-)
Agree. Emacs is so much more than a text editor, it is more accurately described as a lifestyle. Operating systems are merely bootloaders for Emacs. ;D
I've tried several times to get into vim. I feel like it's similar to dvorak though - unless you use it 24/7 you won't develop the muscle memory necessary to use it efficiently.
Maybe 80 hours total, but then that's it. And then you have speedy skills that can serve you in almost any command line environment. AND vi commands are used in a lot of other places, like man pages and such.
it's an up-front cost, but it's one that you'll benefit a lot from over the years.
I recommend starting with soft plaintext, like a diary. Over time, you can migrate to using it to edit code. My conversion took a couple months, and followed this pattern.
I started by editing plaintext diary files. Then, once I was very use to the in-file navigation, I installed vim-mode on my editor of choice at the time, so I could benefit from efficiencies there, while keeping all the IDE benefits.
Then, I began the process of replicating all of the features I used in my IDE, in vim. that took maybe another month, and was motivated by how painfully un-snappy my IDE was relative to vim.
This is all to say, it doesn't have to be an all-or-nothing cutover. That would be painful and frustrating.
It honestly isn't nearly as difficult as learning Dvorak; you can be productive with Vim if you use it full-time for about a week. If you stay dedicated to learning and improving, you can get really good and become pretty productive.
While I love Vim and I use it most of the time, I don't really buy it when people act like it saved them a whole lot of time. I love the Vim keystrokes and philosophy, but I don't really know if I'm any more productive with Vim than I was with Emacs...I stick with Vim because I find that, once you "get it", it's relatively easy to translate stuff from your brain to the screen.
I've always considered that it's more about comfort than productivity. And perhaps that comfort leads to a small increase in productivity, but more because you enjoy it than because it's so much faster to use (as we always say, we spend more time thinking that writing). And because so many tools use vi-style keybindings, if you spend any significant amount of time in a terminal, then you're going to experience that comfort and familiarity all the more.
I wish most of my time was spent writing code, but a vast majority is spent reading it and swearing at my monitor because things don't work, so I don't think even a perfect editor would make me a lot more productive, at least not directly, except (as you stated) maybe through me liking the editor a bit more.
I personally spend as much time as I can in the terminal, and so my "IDE" is actually is typically NeoVim, tmux, some kind of language-server, and a command line. Am I more productive than my peers using IntelliJ because of this setup? Almost certainly not, but I find it very intuitive for me to do stuff with, since I'm super familiar with the tmux keystrokes, and I find Vim's design really intuitive for me.
You don't need to go hard core all at once. Start learning a few commands, such as "i", "a", "x", ":w", then add progressively more to your repertoire.
Oddly enough, learning Dvorak during a [slow] summer internship and then learning to use Vim regexes to edit/search a couple TCP dumps at my first job probably are the reasons I eventually became interested in scripting/programming and eventually a software developer.
Really if it weren't for the first challenge of learning Vim, I wouldn't have learned to program. Which, I know, sounds kind of backwards :P
Do you remember the time when every time you wanted to copy or paste something in a word processor you would dutifully hike your mouse up to the Edit button so you could select "Copy" or "Paste", and how when you learned that CTRL+C and CTRL+V was a thing your mind was blown with how much quicker it was? Vim gives you that experience, except times a gajillion because it not only speeds up what you already do in a WYSIWYG word processor but also gives you powerful new tools to edit that have no WYSIWYG equivalent.
> powerful new tools to edit that have no WYSIWYG equivalent
Can you give an example? I have heard this but I have difficulty understanding exactly what I could do in Vim that I couldn't do in Sublime Text for example
It's not that you "can't" do certain things in Sublime. But Sublime and other "normal" editors have only a few primitives in terms of editing and moving, whereas vim has a language that lets you compose more complex commands from a set of primitives.
The general form of a vim command is:
(repeat)(verb)(motion/object)
That is, I want to perform 'verb' 'repeat' times on a 'motion' or 'object'. Examples:
fX == 'f'ind the next occurrence of character 'X'
3fX == repeat 'fX' 3 times
w == go to the next word on the line
3w == repeat 'w' 3 times, i.e. go 3 words right
dw == delete word
3dw == delete 3 words
dfs == delete to the next occurrence of 's'
yw == "yank" (copy to the buffer) the next word
y3w == yank the next 3 words to the buffer
H, M, L == move the cursor to the top, middle, or bottom of the screen
zz == center the current line of text in the editor window.
8j == move the cursor 8 lines down
ma == create a bookmark 'a'
`a == go to bookmark 'a'
"ay == yank to buffer 'a'
"ap == paste buffer 'a'
. == repeat the last editing command (insert, delete, yank...)
I like vim because its commands are both efficient and precise. I don't need to look and make sure the cursor is at the right position or that I've selected what I want to cut/copy correctly. I know it's correct because I typed it in. And I don't need to move my hand to the mouse or arrow keys. And bookmarks and buffers are great.
Does Sublime support macros? Macros are particularly useful when fixing up semi structured text (like converting a CSV into SQL)
Even then, macros kind of have to be keyboard based, as the keyboard presents a straight forward serialization format. Similar to how macros in non-Lisp languages struggle to achieve an elegance you can't quite capture unless your language is literally a textual AST
But there's also the random things because there's so much. Like ~ to swap case, or Ctrl-A/O for increment/decrement. I find myself in non-vim editors typing "dd" all too often
Vim gives a consistent and quick interface to editing operations based on a set of standard keys with modifiers. But it doesn't try to be everything to everyone. "plugins" for vi, at least in the classic sense, tend to be minimal. The editor relies more on integration with the UNIX ecosystem. This makes vi unlimited in its possibilities, without having to rely on thousands of lines of lisp code, like emacs does.
> rely on thousands of lines of lisp code, like emacs does
Millions actually.
I'm an emacs user (who does not want to get into an editor war, mmkay). The plugins are so useful. I'm just learning magit and it very much takes most of the evil and hostility out of Git and I really like it. I also have dired (a sophisticated directory editor), and about to learn loads more such as Bookmark+ which allows links and jumps to anything you set, and allows you to save your desktop layout and files.
Emacs has so much, if only you can find it (align-regexp is very useful but there is so much more). Edit: look up M-x occurs if you haven't met it. Mega useful.
Consistency is going to be lost as you add functionality. If Vim doesn't have that problem it will in time.
Emacs isn't perfect, the package library melpa has dubious quality software, but emacs really is very good indeed.
That's correct, Emacs is a platform to write applications that can connect to a text editor. This is a different proposition than vi. Like other unix tools, vi goal is to concentrate on one thing (editing), and let the rest, like email reading, git operations, etc., to be handled by other UNIX tools.
I think you misunderstand. Though I've not set up email myself, I believe most email tools export their actual operations to an external tool (gnus may be an excpetion, not sure). I know for a fact that magit, the git interface, delegates directly to git. For source file tags and tag searching it delegates to an external tagger.
I used vi and vim for about 25 years before switching to Emacs.
I did this because:
1 - I got deeply interested in Lisp and Scheme, and Emacs was reputed to have the best editing environment for these languages
2 - Almost all of Emacs itself and Emacs' entire package ecosystem is written in eLisp, which is a tremendous improvement over vimscript, in which almost all vim packages are written. I'd just rather read and write eLisp over vimscript any day.[1]
3 - Emacs offers so much more than vim (or neovim). You read and write your email in Emacs, surf the web in Emacs, chat on IRC in Emacs, have deep shell integration in Emacs[2], read RSS news in Emacs, use org-mode (which vim only has pale imitations of) and do just about everything else you'd ever want in it, which is not really the goal of vim, and certainly the opposite of the minimalism of vi.
4 - Emacs had packages that would emulate vim (evil-mode being by far the best and most complete of them all), which would allow me to bring my decades of vim knowledge and plugins over to Emacs, so I'd feel right at home.
The switch was a success, and I've been using Emacs for about 10 years now. I have no reason to go back, as Emacs does virtually everything vim does and much more than vim doesn't.
There are still a few things I miss from vim, and I still fire it up on systems where Emacs is not installed and where I don't have my Emacs config (I don't like using Emacs' TRAMP mode, for reasons I won't go in to here), and for a few tasks where Emacs just isn't adequate.
For instance for editing files with really long lines or gigantic files which Emacs just chokes on.[3] vim's regex engine also has some features Emacs lacks (ie. vim's \zs and \ze zero-width patterns are ones I sorely miss in Emacs).
Otherwise, though, evil is a pretty feature-complete emulation of vim, and I don't find myself missing the latter much.
It did take me a really, really long time to get my Emacs configured to be the way I liked it, though.. and that's a never-ending process.
So I wouldn't necessarily recommend that other vim veterans switch to Emacs unless they've got a huge amount of time on their hands, love tinkering with their configs, and either already love or are open to learning to love Lisp. I happen to be one of those people, so it's worked well for me.
[1] - Yes, it's possible to write vim packages in Guile Scheme, but virtually no one does this. A Guile Scheme ecosystem doesn't exist for vim, so if I chose to write Guilde Scheme packages for vim, I'd pretty much be the only one doing it. Not so in Emacs, where everyone writes packages in eLisp.
[2] - Emacs' shell integration didn't turn out as great as I expected, as it's vulnerable to Emacs' atrocious handling of long lines, slowness, and buggyness of its shell modes (though libvterm is supposed to offer a real shell inside Emacs, which is reputed to be a lot better than other shell modes written in eLisp, but I haven't tried it).
[3] - vim also isn't great at files with super long lines and gigantic files, but it's better than Emacs.
> I used vi and vim for about 25 years before switching to Emacs.
Then maybe you can help:) I've tried, multiple times, to switch to emacs. And every time, I get stuck, because vim keybindings are so wired in to my muscle memory now, and even the broader interactions are hard to adopt (i.e., I expect to get a command prompt by escaping to command mode and then typing ":", and then all commands are available). Is there any trick that you found helpful to overcome all the inertia?
Try something like spacemacs[1] maybe and use it only for one specific task like org-mode[2]. That way, vim is still your daily driver, but you get to play with lisp/emacs on something very cool like org-mode!
Then, you can slowly try to switch one thing at a time, for example start editing all Dockerfiles in spacemacs, or maybe do that one hello-world project/app in clojure/phoenix using spacemacs. See how you like it, tweak it a bit.
Finally, decide on using it as a daily driver for a new project and stick with it. It will grow on you.
I'd recommend using evil-mode. It'll give you the stock vim keystrokes and the command prompt (ie. what you get when you press the : key).
I was tempted to say "just use evil-mode", but it's really not "just" a matter of using it. evil-mode doesn't get you everything, as many Emacs modes just don't have vim-like bindings, and you'll either need to rebind them all yourself to something that makes sense for you (which is what I did, and I recommend creating lots of hydras to help you remember everything that's available), or you can use something like Spacemacs or Doom which will set up sane defaults for a lot of modes.
I've never used Spacemacs or Doom myself, but I've heard good things about both.. and bad things about Spacemacs, and how Doom is supposed to be an improvement on Spacemacs.. but as I've not used either I can't really comment on how accurate those claims are. I'd suggest doing your own research on those, or maybe someone here can comment on them.
Also, I'd recommend joining #evil-mode on the Frenode IRC network, the Emacs subreddit, and the Emacs StackExchange. You can get all of your questions answered there, and learn a ton about Emacs by reading these.
Yeah, IIRC I've tried Spacemacs and Doom... I think I managed to hit things that they didn't implement... oh, I know: I've gotten the (bad?) habit of going to normal mode by hitting ctrl-c rather than escape, and I think evil didn't handle that. (To be fair: It works in (neo)vim, but ctrl-c to get to normal mode doesn't work nicely in other vi versions either, which is why I suspect it's a bad habit and/or me abusing some misfeature that wasn't intended to be used that way.)
Perhaps I should take another swing at it and see if I can't deal with the quirks...
Yeah, I tried evil (and variants that used it), but the slight edge cases where it didn't quite work like vim messed me up enough to undermine its usefulness. Both in that I actually used things that it didn't provide, and in that hitting some places where it didn't work cast uncertainty over the whole thing: In vim, if I know a keybinding or command, it will work; in evil there was always a moment of "will that work... okay, that does work" that broke my flow (or worse, "okay, let me just... oh, evil doesn't do that, now what?").
With the exception of certain corner cases, when evil-mode doesn't exactly emulate vim it's considered a bug and should be reported as such.
I have run in to some of those corner cases myself, and had to ask myself whether they were worth giving up Emacs and evil for, and the answer for me that was that they weren't. Both are way too useful for me, and an occasional hiccup here and there isn't worth giving them up and going back to vim.
Also, I don't run in to those corner cases very often. Maybe 95% percent or more of the vim commands and features I use myself are completely emulated by evil without issues.
One other thing to ask yourself when running in to such cases is whether they're really an incompleteness in evil's vim emulation or maybe just a lack of a keybinding or some function that you could easily write yourself (if you know eLisp).
It's taken some elbow grease, but I've ironed out a lot of the wrinkles such as missing vim-like keybindings in modes that don't come with them by default (others use spacemacs or doom for this).
It's terribly inefficient for emacs vi emulation mode to actually quit emacs when you type ":q", because it takes much longer for emacs to start up than vi, and people use a long-running emacs a lot differently than they use disposable vi's.
UniPress Emacs's vi emulation mode would actually flip you over to an emacs shell buffer when you typed :q, and the shell would recognize when you typed "vi foo.c" and flip back over to a vi emulator buffer instead of actually running vi, but INSTANTLY, since changing buffers in a running emacs was much faster than actually starting up a new vi process.
So die-hard vi users didn't have to re-learn their muscle memory, and could just stay in the same emacs all the time, while the same old emacs alternately flipped between pretending to be a shell, and pretending to be vi.
"it takes much longer for emacs to start up than vi"
This is false on pretty much any modern system. They start up in about the same amount of time. Using lots of packages (in both vim and Emacs) will slow down startup speed, but there are tricks to speed that up too (like by defering actual loading of them until they're needed).
Also, most people who run Emacs just keep it running all the time, and almost never quit or restart it, so startup speed would not be an issue even if it was slow, which it isn't.
"people use a long-running emacs a lot differently than they use disposable vi's"
Emacs has an emacs-client binary which you can use exactly the way you use a disposable vi (or vim). It'll connect to the long-running Emacs process in the background, but that's an implementation detail that you as an Emacs user wouldn't have to worry about, apart from starting Emacs once when you boot your system.
Regarding your description of shell-flipping, Emacs does offer shell integration, where that sort of thing can be done, but I personally don't use it and run shells outside of Emacs (and run both my shells and Emacs itself under tmux), so my workflow with Emacs and the shell mirrors the traditional vi/vim workflow.
I didn't have to change my decades-old vim muscle memory or workflow when I made the switch to Emacs.
Then whenever you run 'vi' it will create a new frame on an Emacs instance that's running as a server[1]. If there's not an Emacs server already running, then it will start one for you, so the first invocation will be slow, but every subsequent invocation will be fast. No need to change your muscle memory for this particular case.
Also: Emacs has shell windows, process management, and output filtering, and keyboard macros, so it can run and control and respond to sub-processes (kind of like "expect" on steroids).
I could not give up running shells in an emacs shell window, capturing all the output as normal text I can edit and search with the full power of emacs, instead of a dumb scrolling terminal emulator, and the ability to make keyboard macros that hop between text files and dired directory listings and shell windows, copying file names and data to fire off sequences of shell commands. Easy on-the-fly automation of repetitive tasks. Why write a single use shell script when you can just do it once by hand while recording a keyboard macro, then repeat it thousands of times.
Not OP, but that hasn't come up for me very often. If a command output is really long or takes a long time to run I'll normally run it using M-& (async-shell-command) instead of running it in a shell buffer.
Long lines are a more general issue with Emacs, but there's changes in Emacs 27 that should mostly solve it.
The fact that it can happen and does happen leads me to avoid Emacs' shell modes altogether. I just don't want my Emacs freezing on me ever. Considering how much I do in it, it freezing on me is an utter and complete disaster that I want to completely avoid even if it doesn't happen often.
"there's changes in Emacs 27 that should mostly solve it"
If you're talking about the solong mode integration, that's just a hack that kind of works for static buffers, but won't help in dynamic buffers like shell-mode.
To really and truly fix this issue, a core part of Emacs will have to be rewritten, and since that part is written in C and is pretty hairy, no one seems to want to deal with it. So it probably won't happen any time soon.
I'm just hoping Emacs' libvterm integration provides a good workaround, at least for using a shell from within Emacs. I'll have to give it a try one of these days.
>The peak computer speed doubles each year and thus is given by a simple function of time. Specifically, S = 2^(Year-1984), in which S is the peak computer speed attained during each year, expressed in MIPS. -Wikipedia, Joy’s law (computing)
>C++++-=
>“C++++-= is the new language that is a little more than C++ and a lot less.” -Bill Joy
>In this talk from 1991, Bill Joy predicts a new hypothetical language that he calls “C++++-=”, which adds some things to C++, and takes away some other things.
>These are some highlights from a prescient talk by Bill Joy in February of 1991.
>“It’s vintage wnj. When assessing wnj-speak, remember Eric Schmidt’s comment that Bill is almost always qualitatively right, but the time scale is sometimes wrong.” -David Hough
It's amazing how fast one can edit text with vi once you get all the keys down. There used to be a video game that taught how to use VI. Is it still around?
Some things seem unnecessarily unintuitive to me about the shortcuts. For instance, using 4 in-line keys for navigating a 2D space seems like a wasted opportunity. Every video game ever came to the conclusion that the inverse-T layout is ideal for this task.
I mean, putting all they keys in the home row is admirable but the up/down placement seems so counter-intuitive! Almost everywhere I see arrow keys put in a line up comes first…
^H in ASCII is backspace (move carriage to the left), and ^J is linefeed (move carriage down), so h-j were completely intuitive to people who already knew ASCII (i.e. everybody) and then it just makes sense to continue the row of other cursor movements.
vi was written long before any video game ever, and the arrow keys on the ADM-3A terminal that Bill Joy used in 1976 were actually on the hjkl keys, so it made sense at the time.
Interesting! I can imagine it would be quite a bit more intuitive with the arrows written there. It almost makes it seem like the touted benefit of having these keys on the home row is essentially ad-hoc reasoning, and maybe this 35-year-old design decision should be re-visited since even keyboard manufacturers realized this was not the best system decades ago.
Just don't use h and l, really. There are a lot of ways to travel horizontally in vim. The fact that up/down are besides each other is really awesome, since that is the movement you will be doing most of the time.
I don't know, I mean I believe you can learn anything and it will seem intuitive after a while, but I feel like more video-game speed runners and e-sport athletes would map their movement controls to the home row if this was really an advantage.
> It's amazing how fast one can edit text with vi once you get all the keys down
People say this, but I feel the same about VSCode. Once you know a few shortcuts (esp. the multi-select and multi-cursor shortcuts), you can make incredibly powerful bulk changes to a file.
I wish there were a subreddit called "TextEditorWars" or something where a challenge is given, and you can submit a screen capture of you accomplishing the challenge as fast as possible in your editor of choice.
I watch in awe as vim experts fly with amazing speed. They have undeniable powers, built on top of highly personalized .vimrcs. And I try to learn, but get stranded in the very basics.
Example is searching for text on my system clipboard. There's no way to do this in vim: it insists on interpreting special regex chars. If you google it, you will find line noise that you can paste into your vimrc; these solutions inevitably have caveats and are now personalized to you.
(I asked our resident vim expert how he accomplishes this, and he seemed confused why you would ever need to do that. vim is its own universe, huh.)
Anyways looking for practical suggestions for getting into vim - a "cheat sheet" that has actually worked for someone!
I think vi is good. I think the modal editing is good. The ZZT external editor I wrote (ZZTQED, and later frezed) is inspired by features of vi, such as modal editing, numeric prefixes, macros, etc. It is also good that vi has the ability to interact with external programs by pipes, which is something that Heirloom-mailx also does and I like that, and my own NNTP client software (bystand) also does, but unfortunately the web browser doesn't (the web browser is one of the worst software). One problem with many newer programs is lack of good documentation as well as using mouse-based interface; I like to make most functions working by keyboard commands. A lot of existing software I don't like so much, so I try to write my own better ones, which can use pipes with external programs, using mostly keyboard-based interface rather than by the mouse, using UNIX philosophy, using you have enough ropes to hang yourself and also a few more just in case, etc, to do what I will think is a good idea to do. And yet, it isn't just a lot of computer software that is badly designed these days, but even user interfaces of VCRs, DVD recorders, etc. I don't really like MSE so much, so I wrote TeXnicard. I don't really like most NNTP software so much, so I wrote bystand. I don't like KevEdit so much, so I wrote ZZTQED. I don't like Inform so much, so I wrote Glasm. etc
The first editor I used was pico, then nano. I joined a sysadmin team shortly after college and they said they would not install those tools on the Sun servers; I had to learn vi. I wasn't prepared to argue but I wanted to know why. They said you'll find vi on almost every system and it will work fine in almost any terminal. To me there was a lot of value in that, and once I did learn vi, I liked it for all of the other reasons folks are mentioning in this thread.
Ok, I get that vi is a legend etc. I think I understand why, but I'll keep that to myself. But honestly, it's a relic. Hell, it was a relic in the late 80s when I was in college! Few of my classmates bothered with it unless they HAD to use it, which in my view is what makes vi so sticky. We can thank the academic community for perpetuating it as some kind of "expert" tool and encouraging or even requiring students to use it. The same ignorance that keeps CS dogma alive such as "good programmers don't use GUI debuggers or IDEs." My college age kid in CS came home parroting this nonsense. But at this stage of her education I'm quite used to unindoctrinating. There is no reason a university should teach kids to use vi as a primary code editor. It's a crime in the context of a modern, statically typed language such as Java.
But it is an expert tool. Does that mean that a GUI editor isn't? Not at all. But I don't expect my non-programmers friends to use vi/vim (or any person, really), but its definetely something that proves its worth to programmers more than to other people. The elitist attitude is terrible, I agree, and people should use it for whatever they want, but to deny that it is an expert's tool is wrong, imo.
Highly overrated, and I’ve been using Vim professionally (or vim emulators) for ten years now. I’m just used to the keys - muscle memory - but that’s it. (Its actually my first editor, my first job was at a place with a lot of vimsters)
There’s no proof that it makes you more productive or a better programmer. It’s actually gonna trip you up and get in your way if you don’t soup it up like an IDE
If the original vi used 'jkl;' for movement and put a startup message on the screen for newbies explaining how to exit, I'd probably be using it today.
Turns out that was enough to send me on to glorious decades of emacs.
Yesterday I spent an hour trying to figure out how to NOT use vi to make a Mercurial commit on macOS. It was one of my most frustrating computer experiences in recent memory.
My guess is that you ended up on a machine that has the default editor as
vi. TO fix this, set your shell's EDITOR env variable to something like
nano.
I agree that VI's default is so different from the modern editor that it's
very frustrating to get stuck in it. However, learning vi pays dividends.
I tried setting the editor to TextEdit app path. That didn’t work. I also tried Sublime, which also didn’t work.
Setting the editor is really a 3 step process. Add application to PATH. Create an alias. Specify the alias.
VSCode has a command to do steps 1 and 2 for you.
My next weekend project is to learn Vi. (Any tutorial suggestions?) I don’t want to. But I have to. Smartphones are so intuitive toddlers can use them. Vi is so non-intuitive it requires going to external tutorials to learn how to edit text. Sigh. :(
Vi is keyboard only. This means that actions with the mouse are optimized through the keyboard. There are "hotkeys" for most tasks you use with a mouse.
Vi has the idea of objects. Words, lines and paragraphs are objects you can operate on.
Vi defines a "language" for operating on objects. For instance, 'd' is delete. You can delete a word using 'dw'. You can delete 5 words with '5dw'. Another example: deleting a line is 'dd'. Delete 5 lines with '5dd'
It is a modal editor. At a basic level there is an "edit" (insert) mode, a "navigation" (normal) mode, and a "selection" (visual) mode. The power of a modal environment means that commands and hotkeys now have a context and do slightly different things in different modes. While this may be overwhelming, once all these modes are ingrained in you, it allows you to be extremely efficient since you do not have to remember new hotkeys. For example, in the navigation mode, you can apply the 5dd to delete 5 lines. In selection mode, use '5w' to select five words. 'd' now deletes everything in the selection. If you've ever struggled to manage and remember your hotkeys, modal environment is your friend. (set this up in mac using something like hammerspoon.)
It includes some really nice out of the box features: Macro system to save you time with repetitive tasks, regular expressions search and replace, time travel through your edits, it stores your edits in a tree so you can navigate to your changes even after multiple undo/redo. "." repeats the last change. You can also apply a number before it to repeat the change n number of times. I am surprised how often I use this that this is and this is first thing I miss when using another editor.
Vi is worth learning as it will improve your productivity. This is especially important if you have to edit a file on a remote server. Vi is installed on every unix distribution. Many cli tools and shells have a vi mode. This allows you to take the vi 'language' to all these cli tools for more productivity.
For those who struggle to learn, I highly recommend Vim Adventures. After that, force yourself to use vi for your every day edits and it'll be second nature in a couple of weeks.
https://vim-adventures.com