Speaking personally, I've been a professional developer for almost decade and even in my relatively short career I've seen a lot of technologies come and go. I was reluctantly roped into it by my first boss, an enthusiastic Vim advocate. And since, almost nothing else (save for maybe git) beat learning vim from a return on investment perspective. From the default mac OS installation to some old Fedora box that has not been patched since the early 2000s, Vim (or its simpler brother Vi) has always been there!
And once I got used to it, I couldn't really imagine using computers any other way. I'd go so far as to say that the 'home row' concept of vim is the ergonomic ideal of keyboard based computing, and I now try to mimic that behavior everywhere -- the vimium extension in chrome, various vim plugins for vs code and sublime etc. If you're on the fence, I'd urge you to give in!
Definitely, even now as I use emacs, I'm a 100% evil. It's just so natural (once you get it), that I don't know how other bindings (like ctrl-[whatever]) are prevalent in most other software, it's not like they are more memorable or intuitive.
Fun story: I was into Free/Libre software as a teen, when I learnt how to move around in vi(m) and in my first tech gig (as a sysadmin), I was interviewed by some greybeard who wanted me to do some maintenance and configuration tasks. I knew the basics of command line environments, but I had never setup LDAP, mail or DNS. So anyway he asked me to setup some repository on yum, and well, at least I knew how to do that. When he saw me using vi commands to quickly edit the file, he stopped the interview, arguing that anybody who was fluent on vi, was obviously a seasoned admin and I got the postion. I never had the guts to tell him otherwise.
Years of interviewing people for my own teams has shown me that understanding your tools (especially to the point of being opinionated about them) is probably the #1 indicator of success.
Where I work we use a lot of jetbrains IDE's and I've been a massive fan of Intellij, I absolutely love it when I can show someone something that makes their life easier.
Whether it's how to implement an external program properly using all the expansions or how to use bookmarks (how people can use an IDE for years and not find that is a good question).
I've always RTFM of whatever tool I'm using as the first step then I go look at the default keybindings to see what else there is.
The one that blows people away though is the custom exporters you can write for data views, oh you want that result set in a PHP array for a test set, yeah Copy as PHP has you.
Intellij is absurdly powerful without writing custom plugins (which is my next step I guess).
IdeaVim is the uncanny value of vim for me. It's so close to being actual vim, but every now and then it does something unexpected and it completely throws me off.
I recorded a macro to change shouldBe([true|false]) to shouldBe[True|False](). Pretty simple: qqf(ds(~$a()<esc>q
But the vim-surround plugin emulation doesn't work properly with macros, so it'd get stuck and instead of just doing n@@ , I'd have to do n@@( , i.e pass the seperator I used for the delete surround command.
It doesn't have fold toggling, so z[a|A] doesn't work. The undo behaves weird, you usually have to do it twice UNLESS you've not moved the cursor since doing the last edit.
The git integration isn't as good as vim-fugitive and I constantly find my self reaching for the mouse to do anything git related, whereas in vim I could do it all with the keyboard.
The plugin gets brought up all the time when people talk about the JetBrains tools and no one seems to mention the short comings.
(intellij sometimes has recurring problems with lost keyboard input under linux+gnome. IdeaVIM is one of the first plugins i disable, when that happens. and it often helps.)
It's also what's so hard about hiring junior candidates and why so many companies shy away from it.
Truly junior hires don't really know the tools yet. You can't really afford to wait for the rare junior who does, so unfortunately it's not as useful a test in that situation.
That's why I think OP's "seasoned sysadmin" line is perfectly valid. The junior that knows their tools has already cleared the hardest hurdle for most companies. Everything else is trainable through mentorship, but tools usage requires experience.
Indeed, I always advise people who want to be developers to build some stuff to show, to separate yourself from everyone else, and make it easier for the hirer. That is another reason to do it, an IT degree doesn't mean you can write code, as you say the rest can be learnt.
I don't know about that, my first tool was vi, I have strong opinions about it :-). I use an all singing IDE (Appcode) now, its not perfect either but works for now.
I map held Caps to Super (so I can switch windows and use other higher-than-application-level shortcuts without leaving the home row in dwm), but yes, definitely don't limit yourself to one use for your keyboard's most convenient key without a use. In X11 it's as easy as
I really don't like chord like shortcuts, while ctrl and [ are positioned in a way you don't have to contort your hand it kind of requires you to move away from the hjkl row or stretch your pinkies. Consider mapping esc to jk (as a sequence) it works surprisingly well.
inoremap jk <esc>
and
inoremap <esc> <nop>
so that you never use esc again
not having chord like shortcuts was one of the main reasons that led me to try vim over emacs in the beginning, so I kind of think they're "anti" vim.
Having ctrl-[ in your muscle memory has the advantage that it also works in other readline programs that have a vi like interfacee, e.g. bash, zsh and many db consoles.
This is now my muscle memory escape key since an embarrassingly cheap Bluetooth keyboard of mine only allowed escape == home button on my Android devices.
Pro Tip: Park the flesh of your left palm near the left ctrl key and use that instead of your pinky for ctrl. I admit this feels a bit weird at first but avoids the need to lift your fingers from the home row. Super bonus: use ^H for backspace. Try it out!
my reasoning was : you could have mapped caps lock to ESC but you did not. So maybe you are using CTRL too much (CTRL-V maybe?) which is not the best way to use vim.
No your reasoning is way off. I map to ctrl rather than escape because I want to make use of the Insert and Ex mode ctrl shortcuts.
For example, if I want to insert a register into the ex mode command line I use ctr-r <register>.
Or if I want to pop out of insert mode for a single command I use ctr-o.
E.g. inserting opening and closing tags when a suitable plugin isn't present. Insert the opening and closing tag, jump back to command mode with ctrl-o, move backwards and you're ready to insert more text.
Can't speak for everyone, but I use this[1] keyboard most of the time, and it doesn't have a Caps Lock key to remap, but instead has Control where Caps Lock normally is. So using ctrl-[ is much easier than reaching up to the escape key.
Using Ctrl-[ is perfectly fine if that's convenient to you. Some people doe "inoremap jj <esc>" and double tap j to exit insert mode. If it's faster for you than pressing regular escape, it's an improvement, and thus good.
Politely, I'd consider rephrasing this in the future. Not everyone springs forth into the world with a 5kloc .vimrc. Everyone is incrementally learning from someone else at their own pace.
Such a thing is a proxy character trade and probably told him enough. I'm in bioinformatics, if an applicant tells me they studied biology but have always run a Linux server at home, I can also stop the interview: hired.
I've used Emacs for many years, and recently switched to Spacemacs, a set of configs that kind of takes over Emacs and puts a great platform on top of it.
I frequently describe Spacemacs as a better vim than vim. Don't get me wrong, I've used vim for ages; I'll never stop editing server config with vi, nor will I stop getting mad when vi is actually vi and not vim.
But for a day to day code editor? Spacemacs is astonishingly good.
(Of course, Spacemacs is built on top of EVIL, as well as dozens of other packages. On the shoulders of giants, as we say.)
The problem with Emacs and all its modifications is that it cannot match Vim's flexible system for custom keybindings. And because of that Evil mode has the same limitation, beside its insistence to prefer using builtin Emacs functionality over emulating Vim behaviour correctly.
And the other thing that I could never get used to is that Emacs' terminals can't handle ncurses applications. I usually like to run Vim in a terminal multiplexer and combine it with various terminal utilities when needed, and Emacs doesn't support that - unless you run it in a terminal, but then Evil mode stops working properly...
I'm fine with Vim, but I'm glad I tried Emacs for a while because it does have some nice ideas.
> The problem with Emacs and all its modifications is that it cannot match Vim's flexible system for custom keybindings.
Interesting, my impression was that custom keybindings was more flexible in Emacs + Evil than in Vim. It seemed easier to e.g. define new modes with separate keybindings, and if you use the GUI version, more distinct keybindings are available.
> And the other thing that I could never get used to is that Emacs' terminals can't handle ncurses applications.
It can now. The problem is that there are a lot of shells and terminals available in Emacs, so it's not always obvious which one supports what. But emacs-libvterm [1] is a "real" terminal inside Emacs, and supports ncurses apps well. (The website warns about being alpha level, but I used Emacs + Evil for about half a year, and it worked fine for me.)
> The problem with Emacs and all its modifications is that it cannot match Vim's flexible system for custom keybindings. And because of that Evil mode has the same limitation
Can you explain what limitations you mean? What keybindings has vim over emacs?
> And the other thing that I could never get used to is that Emacs' terminals can't handle ncurses applications.
libvterm seems to have solved this problem recently. Works well enough that I can use vim inside emacs.
I have to agree. Emacs w/ Evil is a nice solution and gets almost there, but there are enough edge cases that interfere with the elegance of pure Vim. Everytime you install a new emacs plugin, you have to consider that it will use Emacs keybindings, not Vim, and you jump through hoops to remedy that, or, more often, you find yourself having to mix the emacs ways and the Vim way, which I personally found annoying after awhile.
Emacs is awesome and more powerful overall, but actually using Vim is easier -- from setting up keybindings, configuring your vimrc file, it's all quite simple compared to what you can do, and often do, in setting up Emacs.
But to be honest they are much closer to each other than either is to a more conventional/modern IDE. They are spiritual siblings for sure.
Have you taken a look at Doom Emacs? I liked Spacemacs, but I found Doom more performant, as well as not abstracting too much, which allows you to slowly learn Emacs as you go.
Probably in the minority - I have an extensive custom .emacs.d, but I've kept most of the default emacs bindings. Not only do I find them ergonomic (use the side of your palm for ctrl!), they're also the same bindings you'll find in most terminals. Additionally, emacs does so much more than editing, and having consistent bindings across tasks is really convenient (I'm super lazy :).
I am also surprised by this. What are you basing it on? For arbitrarily comparable online communities, it looks like emacs.stackexchange.com is twice as active as vi.stackexchange.com
> ...the emacs install base is fraction of vi/vim.
> What are you basing it on? ... it looks like emacs.stackexchange.com is twice as active as vi.stackexchange.com
A couple of things about this. For myself and many others, the reason I started vi in the first place is it's been installed by default on many kinds of machines. On SCO Unix and AIX from my youth, for example, this was the editor you used on a vanilla install of a machine to get things going. So this is part of why the install base is larger.
Another part of why the emacs community is more active is that Vi is just an editor, while emacs is more of a programming language and I daresay nearly an operating system in its own right. Because of the amazing power and flexibility of emacs there's a lot more stuff to discuss for Emacs than Vi.
When I was teaching myself to program, I had a night job in a warehouse. It so happened that the inventory software was on a UNIX server, and we accessed it through a terminal emulator from our windows computer. I discovered one day that I could exit the inventory software and end up with a shell prompt, and that the server had Perl available.
My computer books convinced me that emacs was the better editor, but it wasn’t installed on the server. vi was. So I learned vi and Perl on my lunch breaks.
it also has notepad++ at 30.5% - I've seen one or two people who would use notepad++ when nothing else is available, but I don't think many people have it as their primary IDE.
Also, if you sum up all the JetBrains products (which you can get as IntelliJ Ultimate if you shell out the money), you land in the vicinity of 63% (not vim-related but a neat fact)
It's not a comment on quality or usefulness, and only indirectly its resource consumption (vi/vim consumes less than emacs in its default configuration), it's really about standards.
vi and the ex editor language are part of the POSIX standard and were around early in the history of BSD. See the history here: https://en.m.wikipedia.org/wiki/Vi
I love Emacs and have been using it for years but whenever I want to make a really quick edit, i.e. writing a git commit I almost always reach for vi because by the time Emacs loaded I would've been done committing with vi, at least with a slower machine.
I know some people run Emacs in daemon mode, but it's not always convenient to do that
This and when I ssh into any machine, I know there will be a vi at the very least
1) vim is easier on your hands if you're on a high-latency connection (i.e. usable in a terminal) and/or get tired of chording (i.e. having to press Ctrl along with random keys).
2) I've found vim's plugin systems (Pathogen, Vundle, vim-plug) vastly more intuitive than Emacs' version with package-install and activating one of several repositories (Milk, ELPA, MELPA, whatever) - you install the same plugin regardless of whether you're using Vundle or vim-plug
3) vim and its packages are vastly easier to configure - this is subjective and may be much improved in Doom Emacs/Spacemacs, but in general vim packages have a bunch of global variables that you can set to a number or a string whereas most emacs packages need you to define elisp functions and/or nontrivial data structures, with no sane defaults to fall back on if you want things just to work
this is huge flamewar territory, but this is a bit 'off' question wise - alot of the current state of things is due to historical precedent - some details:
- (original) vi was on most unices from the mid-80s onwards out of the box
- (gnu/lucid) emacs was an additional install (not getting into other emacs flavors - original teco emacs was fairly small i believe).
- original vi just had basic editing and at some point a hardcoded lisp mode, no
addons vs gnu emacs which was a programmable editing environment running within a lisp interpreter - remeber in the early days, people built whole custom hardware to be able to run lisp with sufficient complexity (see also: lisp machines, twenex, etc), so using lisp for your editor was in some sense the definition of 'overkill', depending on ones view of what an editor should do
- Also, from late-80s->90s era if you wanted a GUI for your text editor you probably used emacs, and real vi never had a gui option - put another way emacs was the only one of the two linked to gui libraries.
- vim vs vi: most obvious difference (IMHO) feature wise is that vim adds vimscript, which is an interpreted programming language, so now editing modes are extensible, etc (as was the case in emacs before). detail: vim codebase is not based on vi codebase.
since vi was just about everywhere and emacs was a (fairly large) package, you had more general vi knowledge vs emacs 'in the culture' since even an emacs user might need to know vi but not usually the other way around, and so vi (later vim, as linux distros switched their 'default vi' to 'vim') gained more install base by default. Then, people hearing about emacs likely hear the 'vi vs emacs' arguments and never try it since there are now many more choices, they've learned vi, they prefer an IDE, etc (in the old days there was much less choice, main 2 were vi and emacs, and emacs was probably somewhere on your managed LAN somewhere if you wanted to give it a shot)
most of the 'vi vs emacs' arguments are rooted in the real-vi vs fsf-emacs era and are basically obsolete in a modern vim era, since everyone is using gui library vim with vimscript, which basically means the same thing in terms of 'bloat' (both editors contain engines to display text in cli or gui mode and embed a language interpreter). Basically what was once valid internet lore kept getting past down, and the 'minimalism' of vim was confused with being 'minimal' in terms of what people meant in the original vi-vs-emacs discussions. Emacs does contain 'non editor' functions e.g. networking, etc, so the core is probably a bit bigger than the core of vim, but when people are still using these comparisons and talking about 'emacs bloat' while their preferred editor is some electron based thing, we've lost a bit of the point/message..
> vim vs vi: most obvious difference (IMHO) feature wise is that vim adds vimscript
IMHO, the most obvious difference is that in vim you can kinda just press "i" and pretend its a normal text editor. You know, the kind anyone coming from another OS would already be familiar with. Try doing this in regular vi, and you'll be cursing and pulling your hair out.
Today, I don't put much stock into anyone expressing an opinion in the "vi vs emacs" wars, because 90% of the people claiming a preference for vi seem to actually be vim users. Using vim is a much more pleasant experience than using good old classic vi.
100% concur with this. I learnt Vim many years ago and I genuinely don't know what I'd do without it. It's always just there when I ssh into a new server. And the JetBrains suite has an awesome vim mode meaning I can use most (but not all) vim shortcuts with an actual IDE. I don't think vim itself works well as an IDE substitute, and wouldn't use it for hardcore web dev for example - but for quickly editing random files there's nothing that comes close.
If one wants to do web dev on vim I strongly recommend neovim setup with coc.nvim. I know some people strongly disagree with transforming vim into and IDE, but this is a really productive setup for creating code (works like a charm for my current React project)
Personally I’ll sometimes use VSCode to browse big files or explore the codebase, but when it comes to editing them neovim with coc, fzf and a language pack is all you need.
>>I don't think vim itself works well as an IDE substitute, and wouldn't use it for hardcore web dev for example - but for quickly editing random files there's nothing that comes close.
Exactly my thoughts, you need vim and emacs these days if you want to munge through large amounts of text. The thing is in these days of Kibana and Elastic search. You don't do much of this kind of work anymore.
Code is text. But it's not that kind of text where you need your fingers and macros to do much work. Your tool needs to be at least to some extent aware and intelligent of code you are working with, or you end up doing too much work for nothing. If your language doesn't have this kind of tooling and you wish to maintain your application for long, you need to use a better commonly used language.
Much of the vim macro work I could put to use is done by black these days. If you are writing too much repeated code, you need to learn to write reusable code. Navigation is one more of those things which could improve if you use intellisense.
Bulk of modern day dev work requires working with 2 - 3 tech stacks. The use case for vim, which is writing few key stroke in one attempt to transmit them over super slow internet connections, doesn't exist anymore.
I'll argue that the IDE is Unix, not vim, I recently started and endeavour to vanilla Vim and I was baffled by what is possible even without plugins, granted I mostly work with C and a bit of Python, but one thing to consider is that most people using Vim come from an IDE background, so horse for course I guess.
IDE has syntactic understanding of your code, which allows you to navigate your whole codebase as if it's one big hypertext document (invalueable especially when learning new code). Also, the syntactic understanding allows you to do one-click fairly complex refactorings with guarantees that nothing will get broken (at least it works for sane languages, like Java. I don't know how well it works for C/C++, where preprocessor macros complicate things). I don't see how "UNIX as an IDE" delivers this.
Yeah, UNIX doesn't do that on its own. You can grep, or run find and do a bash loop and so on, which is cool. But it's language servers that give semantic understanding of your code. You can easily refactor, or go to definition from vim. So UNIX is a development environment, very flexible, yes, just not that integrated.
I have mainly used vim for development and I can navigate my codebase just as seamlessly with ctags-generated indexes.
I'd agree on vim being of limited utility when it comes to automated refactoring (it's a text editor after all), but beyond changing the names or extracting functions what can an IDE do for you in this respect?
Refactoring in IDEA also allow you to for example also change function signature, safely delete an element (class, function etc.) - i.e. with full impact analysis, move code, extract interface/trait out of a class.
I've tried the ctags-indexes with Sublime and afair the basic navigation was not bad (I think I remember there being an issue with some delay though? It was a while ago). I'm not sure if things like "show code which access this variable" or "show all children of this class" are supported though?
Apart from those advantanges, I can think of two more:
1. IDE can import your build file (maven, sbt or bazel project for example), parse out the project structure from it and download the necessary dependencies. I don't think that ctags-like powered solution is as robust, which means you'd have to fiddle with it until it can understand the structure a complex repo.
2. IDE can run and show the results of unit tests. (just right-click on test you want and select "Run" from context menu).
My build tool spat out a 700MB compile_commands.json file, which the C++ language server turned into 25k files. None of the language server implementations were able to process even a go to file on the code.
it takes about 15 minutes for Visual Studio (well, visual assist) to generate the index for the project, and then the navigation is instant. I've tried a few times over the last few years with various language server and clients, and my experience has been the same pretty much every time.
You can use ctags/cscope to handle that, FWIW languages like C and C++ have a massive toolset built around Vim, so even for the most obscure use case, I'm pretty sure there will be a way.
> at least it works for sane languages, like Java.
You lost me here.
> I don't see how "UNIX as an IDE" delivers this.
Have you read the linked series of articles? The author explains and provide examples with C and Perl, Iirc there's a book about working with Makefiles in Java, so it's totally doable, painful, but doable.
The use case of vim is not using an insane amount amount of arrows/ctrl/shift for everything.
It's like a mechanic using just one adjustable spanner and one screwdriver to e.g. replace a clutch. It's ok if you really don't have anything else, but any good mechanic will use a set of good tools. (sorry in advance for the car analogy).
BTW a modern vim setup with CoC is not very short of an IDE, but at lightspeed.
I tried getting vim to match my favorite features in VSCode / Jetbrains IDEs and almost went crazy. Rather simple things like code completion or syntax highlighting were already moderately complex to set up. The command palette present in both Jetbrains and VSCode also has thousands of actions easily searchable in plain language, the most simple of which can be replicated with vim (ex: open file) but many of which would likely require some heavy extra configuration. I never even got into replicating things like live templates which are a massive productivity booster for me - I simply gave up.
For me it’s much easier to install the vim plugin in my IDE or editor of choice. I get the modal editing goodness of vim with a supercharged layer of utilities that work out of the box.
The most important part of my point is not that I believe that they can’t be replicated, it’s that an IDE offers them with a time investment that’s nearly zero (I spend a couple hours per year fiddling with my IDE settings, tops).
I’d add that I am also quite doubtful that although they may be replicated, in many cases there aren’t going to be gotchas and UX problems not present in one of the popular IDEs. I can’t remember the specifics but I know that when I set up code completion in vim it wasn’t nearly as good as the one in my editor.
Never heard of spacevim but I have tried a few other “plug-and-play” vim adjutants like Pathogen and always ended up running into problems and spending more time on the issue than I had signed up for. Might solve some of the problems I mention, but I’m afraid it’s too late for me.
My IDE does everything I need and more, working out of the box on all machines I own (they’re not even that powerful) with fantastic UX and minimal fuss. I’m a Jetbrains guy so it costs me 6€/month but amortized per hour spent it might as well be free. If I wanted to save that nominal cost I’d go with VSCode, which I’ve worked with before and is nearly as good.
I’d turn this around and ask, why would I ever switch to pure vim?
There are things like refactoring which technically are supported by vim extensions, but are just utterly inferior to the dedicated IDEs.
For example - you know "extract method" refactoring. Pretty basic thing and I assume vim can do that. But on top of that when you extract the method, Intellij will go through rest of your code and try to figure out if some other parts could be automatically refactored to use this new extracted method as well. It will offer to change the method signature if needed to do that as well.
Intellij will - as you type - notify that the code you're writing is structurally duplicating an existing code and offer an intention to automatically refactor the code to remove the duplication.
Intellij offers an integration with databases - in my code I use a lot of SQL queries - intellij can connect to the data source and scan the schema. When you then type queries into strings, Intellij recognizes them as such, offers autocomplete to the tables/column and validates the query for correctness (also allows you to click through to the actual data view). It understands like 20 SQL dialects and things like JPQL as well.
Another example is the deep flow analysis which can point out logical mistakes as you type (things like NPEs). This is very helpful in daily programming, extreme example of that is shown here: https://blog.jetbrains.com/idea/2019/11/intellij-ideas-stati...
Most of the time when people showed me a "vim IDE", it looked like IDE from the 90s - highlight was that it showed you the list of class members, had a snippet manager and could sort of rename a variable. State of the art is much farther since the 90s though ...
That sounds very useful and it's not something that vim gives you out of the box but I'm not sure that anything you're describing is not possible via LSP plugins and extensions.
Running a server to automatically search for duplicate code sounds exactly like the kind of task that LSP can handle.
Since VSCode has tools for deep flow analysis (although I can't say how they compare to Intellij) then I'm pretty sure I can access them from neovim.
Maybe if I was a Java developer something like Intellij would look more attractive but I've never really been impressed with the rest of the JetBrains IDE family.
Horses for courses I guess. If there's some tool you want that's only available in Intellij then that's what you'll use.
All of that is of course theoretically possible with LSP or other vim extensions. It's just that nobody did it.
Another thing is the level of integration. There are many tools which offer static analysis, duplicate detection etc. But it's completely different level of usability when you see this info immediately as you type.
Yeah, I know that you can use LSP in vim. But LSP for most languages is a far cry from what you can get in "real" IDEs.
It's always "LSP could be just as good" or "support for that can be easily added" - but it's just not happening - nobody does the work to make that just as good.
I've used vi for 25 years now, starting on a m68k based BSD machine. It's an adequate editor, handy in remote shell sessions and good to know how to use, but I'd MUCH rather use an IDE or a windowed editor with menus and mouse and hotkeys like Sublime. I mean real hotkeys, not emacs.
At the end of the day, it takes a certain kind of mind to like vi, and if you're not of that mind, you probably never will be.
My argument isn't that vi/vim/neovim are not superior editors but the editing grammar is a superior way of thinking about text. This grammar can be reasonably replicated in any environment, and confusing the grammar for the editor is what makes people make such claims.
This is coming from someone who lives in vim for his daily work, likes it, but always finds annoying sharp edges that are hard to reason about and script away.
I think it depends heavily on what you're doing. My world is full of YAML/HCL/cnf files, and if I'm writing code, Go, where code is for software that runs from the command line, a daemon, or a no frills API/web service. Atom/VSCode and other IDE's were wasted on me, so I found myself gravitating back to Vim for its ease of use for those use cases. That said, vim-bootstrap did save me effort of getting a pretty solid editor out of Vim without having to think too hard about it.
Hated Vi at first. Absolutely loathed it. I was all about emacs.
But I gave vi another shot, and I'm so glad I did. The learning curve can be steep, and it's really unintuitive at first (or it was for me). But once it clicks a little bit, and you settle in.. Wow. I felt way more productive using it than any other editor.
I've been using vim for ~8 years now as my editor at work. I don't even use the "fancy" movements that everyone always brags about. It's still way more convenient to move around in than any other editor I've used.
I don't know where I saw it, but the idea that "Code exists to be read" really resonates with me. I don't care how fast I can crank out code. I care about how efficiently I can hop around from place to place to grok what is going on and how it needs to change.
The killer feature of vim that I feel like very few people know about is it's remote editor feature.
Launch a long lived instance of vim with a `servername` set, for example I do: `vim --servername EDITOR`
Then set up a application shortcut that will open the file using the prefix `vim --servername EDITOR --remote <file>`
When you open a file, it gets opened in your single vim instance.
From there you can navigate between all your open files using `:b <file-tab-complete>`
It's really a joy to use. You don't have the mess of tabs where you run out of space super fast, you just have a bunch of open files that you can switch between super easily by name.
This just sounds like a nightmare to me. I can't stand it when I have a terminal program with an unseeable list of files/panes that have to be opaquely navigated through. I very much want to be one of those vim/emacs ninjas but I just don't see how this is more ergonomic than Jetbrains where any file - not just 'open' ones - is readily available with all sorts of search methods with a single shortcut. And then I can visually see what files I'm working with instead of groping around through one file at a time in the dark.
> I just don't see how this is more ergonomic than Jetbrains where any file - not just 'open' ones - is readily available with all sorts of search methods with a single shortcut.
I would guess the difference is that I use a separate terminal window for all of that stuff. I have my desktop split into three main workspaces. The first has my terminal, the second my browser, the third my editor. I have two more workspaces just in case, but they rarely get used. I have shortcuts set up to hop between workspaces using `<super><workspace number>`.
If I want to track through where something is used or defined, `git grep` usually gets me what I want. From there, if there is a file I want to look at, I use my shortcut `go <filename>` to open it. This used to be an alias for `gnome-open`, but a couple years ago they switched it to `xdg-open` . It opens the file with whatever program would open it when opening it from the file browser, which for any text file is my vim instance over in workspace 3.
I don't pay much attention to which files are open or not. Usually I build up a working set of files I care about pretty quickly and then I can hop between them from within vim. Otherwise I can easily go back over to my terminal and open it by name directly.
It may not be for you, but it's far from a nightmare in my experience.
> It may not be for you, but it's far from a nightmare in my experience.
Right, everyone has their preferences. As was said in another comment, merely paying attention to and adapting one's personal tooling is a huge differentiator between software developers, regardless of which particular tools those might be. Your setup has a lot of conceptual similarities to mine. I use terminals heavily, but ultimately I personally like a GUI as the 'root' of my working space. I'd rather start from a place where I can navigate everything visually/spatially and then add shortcuts on top of that to automate the most repetitive/tedious paths that naturally occur in that environment.
>The killer feature of vim that I feel like very few people know about is it's remote editor feature.
Now this is dope, I used to rely on a trick I discovered in a conference[0], append to the `path` variable in your .vimrc so you can recursively fuzzy find files in the directory where you opened Vim, and more recently setting global marks[1] in the files of interest.
Strongly agree -- I mapped my whole keyboard to always have caps/esc swapped. It didn't take long to get used to. My left hand feels way better, not needing to reach very far.
Biggest downside is using someone else's keyboard. I've grown a nasty habit of hitting escape instinctually, every time I finish typing something. I turn on their caps lock so regularly! Still worth it though
I still use caps lock since I regularly code in POSIX shell, C, C++, and Perl, which all have naming conventions that use all-caps names.
Also, as a VIM user, I only have to use Alt when I’m dealing with GUI apps, which is definitely common, but a time when I don’t mind moving my hands around.
So for me, Esc is Alt. Alt is caps lock. And of course caps lock is Esc.
And I swap Super key and Control, since the Super key is easier to press with my palm on my ergonomic keyboard. And Ctrl does have a lot of uses in Vim.
I also map the Windows Menu key (not the Super key, but the other one which is used for showing context menus) To underscore. That helps me type C identifiers with multiple words in them. This one remapping is a huge benefit, almost as important as mapping caps lock to Esc.
Try it (or swap caps and control for day, to make sure you don't accidentally "cheat"). On most keyboards reaching the control key is very unergonomic compared to the capslock key. I wonder how many cases of RSI could be avoided by this simple tweak alone.
I strongly agree, but would go one step further and just remap caps lock to escape for the entire OS. Caps lock is a relatively useless function that takes up extremely prime real estate.
You can also do the remapping in hardware. Programmable keyboards are quite popular these days (I built one out of a $3 stm32f103), and they don't rely on the OS to help you do what you want to do.
(This is a blessing and a curse. You never have to worry about OS-level hacks to make caps lock a control key, but on the other hand, there is no way in the USB HID protocol to say "send an !". Rather, the keyboard has to synthesize a shift + 1. And what character that actually maps to depends on your OS, because of course it does.)
I still get some mileage out of my caps lock key and use "jj" and use paste mode if I have to insert an uncommon string with "jj" in it. Usually pasting it anyway.
I tried that `jj` or `jk` thing for a while and it just did not click with me at all.
I tried it because I was having a bunch of wrist pain. The actual solution to my wrist pain was easy: Don't code on a laptop keyboard. The ergonomics are terrible.
One thing I like about vim is that the defaults are more sane than emacs. Almost no one uses emacs out of the box without extensive customizations. People customize vi too, but out of the box it is already pretty close to being there on its own, which is really nice.
I'm quite the opposite. I keep trying to make vim my main devtool but I just can't stay away from a fully fledged ide. At the same time, having heard from literally everyone that once you do get used to it, vim is way faster to do everything in.
What advice do you have for someone like me to proper get used it once and for all? Are there any good resources you used to learn all the vim shortcuts?
My advice would be to start with the bare minimum: Using [i] to enter insert mode, [ESC] to get back to command mode, arrow keys to move around in either mode. With this you can use vim like Notepad.
Then observe yourself doing stuff and whenever you think "there must be a better way to do X", find out and learn how to do just that. (You would ideally have a cheatsheet on your desk for quick reference. If it's not on there, search the internet.)
At this point, it also helps to know about the basic grammar of normal-mode commands: motions as subjects, commands as verbs. Full sentences are either only-motion, command-motion, count-command-motion or command-count-motion. So if you have already learned that "dw" deletes a word, you immediately know that "d2w" or "2dw" deletes two words.
There's not much more to it. Just do your actual text editing and if you ever find yourself thinking "there must be a better way to do this", that's another learning opportunity.
It's a lot like language learning, really. You can plow through 10,000 vocabulary words in your SRS if you want, but nothing beats actually using the language.
Personally, I find most modern IDE features are overrated and not necessary for productivity. For example, context-aware autocompletion is not necessary -- simple autocompletion based on things you've recently typed or that are open already in another buffer covers at least 90% of autocompletions I need. For the rest, I just have to type it out myself once, and now it is remembered too.
The same is true for browsing a file tree of your project, using syntax linters or reformatters, etc -- all of these are pretty straightfoward to setup in vim or emacs.
It can get a little tricker when dealing with breakpoint debugging, though. But in those cases, I just open in another IDE anyway that has extensive profiling tools, which vim does not have. But that's maybe once a week at most.
Same as you. I've ended up accepting that whatever the features or the plugins, the UX constraints in terminal editors (1-character unit of space, colors, graphical plugins...) will always be a huge limitation. That's reason enough to convince me to use VSCode or Webstorm with a vim plugin
If you like vimium, you may also like qutebrowser. It's built with keyboard bindings from the ground up, and is keyboard-first. I can browse most sites without taking my hands off the home row.
I use both QuteBrowser and Firefox with Vim Vixen, one of the thing that make me reluctant to switch completely are mostly addons, Multi-Container, cookies auto delete, ublock origin, Privacy Badger, ... I can't browse the Internet without those, and the built-in adblocker of QB is unfortunately not that performant.
Also, you can't use the keyboard everywhere (thanks to the modern web)
Random example off the top of my head: https://questions.wizardzines.com/event-loops.html
The way I use qb is I've switched javascript.enabled to false, and occasionally session-enable it for some sites (by default, this is done by typing tsh)
I have also written off a portion of the web as not being worth mytime, however.
never heard about qutebrowser and it can even play netflix, impressive, it's a little memory hungry though, with just netflix running I saw memory is used almost 1GB, while 30 chrome tabs use 4.5GB
I was in the same boat. First real gig out of college (well besides the stints during college) and I saw how fast my boss flew on his keyboard while editing files in vi/vim. Here I was painfully editing config files in nano while he was flying by with vim.
I took the time to learn it and have been using it since. I now try to pass the torch by showing folks on my team the neat things vi/vim can do. People are amazed how much you can do it with just few short keystrokes.
I was interested in programming, don't really know why but the thought fascinated me to be able to instruct a computer to do things you want it to do. So I had tinkered with QBasic and Pascal. A friend of mine went the C/C++ route which lead to us arguing like cat-and-dog (surely out of boredom) about the various benefits.
Then we mutually tried out linux and editors. He picked Emacs, so I went with vim. Haven't regretted it ever since.
What has always kept me from learning Vim is my non-English keyboard layout. Many of the default key combinations are impossible or require some serious finger acrobatics.
Sure, I could try figuring out a new set of easily reachable and non-conflicting keybindings for my own machines, but much of my motivation for learning it in the first place was being able to work on remote machines more comfortably.
Try out a US* QWERTY keyboard for a few months. I grew up with non-English keyboards, but then some years ago I got stuck with a US keyboard for half a year, and after that I didn't want to go back. I can easily type the few non-English characters I need with the X.org compose key, so I can easily write in my native language. I assume it would work equally well for any language using a Latin-script alphabet.
Interesting point, and a good reminder of how anglocentric the computing world is in some ways. Do localized IDEs typically take this into consideration?
This comes from an emacser. Emacs who shares this trait a bit (albeit rarely installed by default) .. when sublime text was all the rage I saw how emacs had 50% of it builtin and the rest was absorbed in a few monthes. I felt emacs would never fade at that point.
Same experience here. Before learning vim I never expected its interface to make such a difference (it seemed daunting and unergonomic). I think the only other software that has made me feel that way is i3.
Nowadays Vim isn't just Vim the text editor but rather a specification for text manipulation. All of the popular IDEs have Vim plugins and the benefits of learning both are perfectly additive.
> And since, almost nothing else (save for maybe git) beat learning vim from a return on investment perspective
Same here. Love high ROI tools where the rug doesn't get pulled from underneath me ever year or two. Linux console tools, bash, vim, etc. My vim config dates back 20+ years, with only small modifications. I can log in into just about any *nix machine made in the last 30 years and be able to edit text at least somewhat comfortably. It takes me 30 seconds to set up a fresh Linux machine to my liking: clone a repo and run a script to symlink things to the right places in home dir. Done. I can also comfortably work from anywhere in the world over a crappy SSH connection.
C++ is the same. Glacial pace of change, skills from 20 years ago are still good with minimal modifications. 20 years from now it'll still be in use and it'll still be about the same. Which is exactly how I like it.
Another good thing about these gnarly old tools is that they weed out the dumb and impatient. I strongly suspect Rust is the same way - the learning curve and feature set look formidable. Lesser engineers are unlikely to ever learn it to the extent required to enjoy working in it. There's value in that, so I might learn it as well once they stop screwing with the core libs. I have work to do, I have no patience for such things.
> C++ is the same. Glacial pace of change, skills from 20 years ago are still good with minimal modifications. 20 years from now it'll still be in use and it'll still be about the same. Which is exactly how I like it.
This gave me a bit of a chuckle since any modern serious C++ work is really a different language since 2011. Most of the C++ prior to that are considered anti-patterns now. It's hard moving at a glacial pace; the language gets major evolutions every 3 years.
Controversial comment here, but I would say Vim isn't popular at all. I would say instead, Vim advocates are incredibly vocal (a bit like Vegans and Crossfitters) and won't hesitate to talk about it at all times.
I've been engineering now since 2002 so approaching 20 years and sure, every office has one guy who's the "hardcore" Vim guy. Everyone else in the office uses Visual Studio or VSCode, Atom, Sublime, IntelliJ etc. But the "Vim guy" is the by far the loudest guy in the room when it comes to discussing his editor, tries to tell everyone else why their editor sucks, how superior Vim is, etc etc. Meanwhile all the users of VS and other editors quietly get along with their work and feel no reason to advocate for their editor like it was a religion.
At my current company it's the same. We have maybe 300 engineers. 99% of them use VS or VSCode, there's probably one or two guys using Vim and still telling everyone else they're dumb for using VS... In 50 years when things have changed completely, there will probably still be some guys using Vim telling everyone else they're wrong for using VR Coding with voice recognition (or whatever is happening in the world of coding then).
In my experience, after University, I never see team members extensively dispute on this topic. I have a strong preference for Vim, but if other are fine with other tools, that's nice. We can possibly show each other how we manage things differently.
It's not like Vim is perfect, and even taken the sharp learning curve apart, there are many things that are not ideal. But so are other tools. I tried some IDE here and there, but never found an improvement in my productivity – which would be certainly easier to improve by not going to sites like Hackernews. :D
I do find some things in some IDE horrifying, like having the amount of RAM consumed by the application displayed in the default interface, and seeing it growing while you don't ask anything to the application. I mean, even dropping the fact that it does require so much resource to do nothing, what a strange idea to clutter the interface with this data if the goal is to let users focus on there issues.
But that's no reason to be zealot of any other editor, including Vim. I'm rather confident that going with a matrix with measurable metrics, Vim wouldn't have rated 100% everywhere nor any other tool would.
To me the greatest feature of vim is that it's available virtually everywhere, so you can take it and the skill you gained on it everywhere. It doesn't make it something should use all the time, but it makes the point on how it might worth the effort to start learning it. That also a positive retro-active loop, that explain "why Vim is so popular", I guess.
Code browsing and inspection is somewhat hampered by the fact its CLI.
I use ctags and macros to move around code but its not always perfect.
But then again there are many things I dislike in modern IDEs,
I don't think there is a ideal solution, just like there is no one language to solve all problems.
> Code browsing and inspection is somewhat hampered by the fact its CLI.
That's interesting because code browsing and inspection are by far the most important reason why I use a modern IDE. I tolerate all their weaknesses (slow, high memory consumption, errors after updates, etc.) because of this. I am surprised that somebody would say "I am using editor XYZ despite its weaknesses in code browsing and inspection".
It's always seemed to me that vim and other lightweight editors are most popular among people who are working in dynamic and functional languages, and heavyweight IDEs are most popular among people who are working in big, static, enterprisey OO languages like C++, Java and C#.
In many cases it's better than an IDE because the code-inspection, linting, etc etc, can be done using the same exact tools as what your CI is using behind the scenes.
Also, having a languageserver for Rust/C++/JavaScript/TypeScript/Bash etc etc, all configured through coc avoids a lot of the jumping between IDEs/editors/tools to get reasonable completion and code navigation between each.
Vanilla Vim I would agree is not good for code browsing and inspection, but two things I've noticed when coding with Vim:
1. Code Browsing is an initial, one time cost when learning the code base. After you learn the code base, I've needed this ability much less.
2. Adding plugins like NERDTree and fzf/ripgrep have helped make code browsing much easier in Vim. The downside to this is that if you're new to Vim, you need to learn how to use these plugins on top of learning how to Vim. So it's just more to learn. But you can also think of this as another one time cost in general.
What Vim lacks in browsing/inspecting code it makes up for with the speed you can make edits - using motions and macros can make tedious code changes nearly effortless.
I've been a Windows admin before but now on an app support team running almost all Windows systems as an analyst but came from a poly sci degree. My Linux experience is homelab and a few work connected systems over time like a Ubuntu Server box that managed IP cameras on site. My experience with coding is mostly Windows automation via PowerShell and its built into Windows IDE as I need a dev role here to get like Visual studio. Even then it would be overkill for what I'm writing like temp cleanup, file transfer, monitoring, etc with my recent success was a script that checks every day for a set of reports we should have received and ingested overnight and lists what is missing then emails that info to myself and another team member. Super helpful to double check the business has the reports they need at the start of the day and get us a head start troubleshooting.
With that in mind, I've used VIM for probably under 10 hours total, mostly for editing config files within headless Linux installs. For example, setting a static IP in Raspbian so I could SSH in once I put the pi somewhere it was online but not physically accessible. VIM is really neat for stuff like that. I'd love to have more reason to learn the interface but barring a weekly use I'd quickly lose familiarity and am focusing on javascript functionality as one of our apps can run js scripts.
So for quickly editing files with a known structure like setting an IP address in Linux or updating code you understand, I can totally see how VIM is amazing. Lightwight, almost always there already so standardized, quick to navigate when familiar, and more. As a fairly novice level coder I'll stick to an IDE with scroll ability and a mouse/etc for coding, even for a slight update to something I wrote the previous day. I'm just not confident in getting it right the first time and know how to test or trial/error a command in an IDE much easier than CLI. If I was trained and focused on coding I bet I'd be way better at that stuff too.
> As a fairly novice level coder I'll stick to an IDE with scroll ability and a mouse/etc for coding
Check out gvim - it's a graphical version of vim that gives you scrolling and mouse support.
It's not quite as graphical as a regular IDE but basic stuff like mouse and scrolling is fully supported. You can even use the mouse to e.g. resize tiled windows within the editor.
There are graphical versions of vim. Gvim is my main editor. It's a bit of a hybrid, since many things that would exploit the GUI in an IDE are still textual in vim. But it has quite a few benefits over pure command line.
People could select more than one option in that survey (87,317 responses; select all that apply). You'll notice that the results add up to more than 100%. Most people who have to remote in to a server will be forced into using Vim sometimes, which will skew the results. Also, I would say that people who would respond to a SO survey arent a representative sample of all developers.
I do not use Vim as a daily driver at all, but I have to use it sometimes because I have no other choice (remoted in to a box). So if I had to say which editors I used, Vim would be there... sometimes.
You're misinterpreting that graph. The key detail to note there is that the bars don't add up to 100%. Meaning that it's showing what percentage of people use that IDE/editor at all. The phrasing, "~25% of web devs... used vim as their editor," implies that 1 in 4 web devs use it as their primary or preferred editor, which is not something that can be inferred from the data.
For my part, when I answered the survey, I checked vscode, intellij, vim, jupyter, emacs, and rstudio. Most of those are there because they're my preferred editor for some task or other, but vim is only there because it's the only editor I can expect to have available on every server I ssh into. So, while I did say that I use vim in the survey, I would encourage you not to count me as a vim user for the purposes of any popularity debates.
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
I think it's highly industry and probably project dependent.
If company policy is that "we use X", then probably you're not going to have many people stray from that. The bigger the organization, the more likely you are to have strict guidelines in place like that.
I would guess people on Windows are also less likely to reach for Vim than any of the many other alternatives. If you're using Linux, you probably have a different view on the world to begin with, and are more likely to go with vim over whatever is the "new hot editor". I've heard Mac users like to reach for XCode, but I don't actually know many developers outside of work, and none of them use Macs, so I don't know.
Besides the other facts mentioned by the other commenters, Vim has a sort of geek-chic aspect to it. It's "cool" to be a Vim user in certain circles. That inflates the numbers plus it also causes a "New Year's resolution" effect where someone would say they use it just because they know :wq and this year they're really, really going to go to the gym, oh, sorry, going to use Vim proficiently for a real project.
Almost every editor allows you to interact with it as though it's Vim. But most editors don't allow you to interact with them as though they're any other editor. I think that's a point in Vim's favor?
(I certainly don't use Vim for most of my coding. It's not good enough. But I do use Vi keybindings in VSCode, Visual Studio and PhpStorm depending on what language I'm using. I'm not particular enamored of VSCode either, btw, for the same reason that Vim isn't good enough - sure, it can do what you want. But you can't guess how to do it. You need to read the documentation. VSCode one ups Vim in just one way - it has a gui for searching and installing plugins. Visual Studio and PhpStorm allow you to browse the menus to find the facility you want. It may take for ever, but when you have some downtime, you can browse and use your learnings next time.)
This. I just want hjkl and dd in every editor, but I don't use any other vim idiom often, and things like multiple cursors or alt+up/down move lines are the editor's fancy features I rely on most. (Sadly the VS Code vim plugin is broken all the time)
But hjkl I need even in my webbrowser. (In Thunderbird I've send many mails to junk by accident.)
Pretty much this. I'm learning Godot and love almost everything about it over Unity... except that its IDE doesn't have a vim-mode, which is ALMOST a deal-breaker.
That is too bad. I'm a Vim user and combine the best of both worlds: vim plugin in VSCode.
A few of my colleagues are vim users, and fortunately for the others we are not as vocal as you describe. I already accepted of being the weirdo that uses vim, because my programming skills make up for it ;).
I do have a shortcut to disable it, when we do some pair programming.
How is that these days? I used it a couple of years ago but it had issues at the time, namely some performance problems and getting stuck in a particular mode.
I ended up abandoning vim bindings because the JetBrains plugin was also buggy, and I straight up had no feasible way to get those bindings in Xcode, but I hold out hope for a glorious LSP-based future where I can just use vim and get all the benefits of my other editors.
There are a few. I am using VSCodeVim[1] with the default settings (besides the typical `jj` command)
I love it, and using anything else feels weird. I remember having some problems with it before as well, but I haven't bothered looking at the settings or anything for months. I had to go back just now to see if I had any weird configs set up, (I don't)
Coc.nvim is awesome. Instead of trying to bring the UI of vim to another editor, coc.nvim brings the "backend" of the other editor to vim.
I tried using VSCode with the Vim plugin for a while but the latency and inconsistencies eventually got me back to proper (neo)vim. UIs are almost always more complex and subtle than people intuit, have a large surface area, and make lag and inconsistencies most noticeable.
Most vegans are actually quite quiet about it, so it’s a sort of survivorship bias, where you simply have no way to find out how many non vocal vim users out there :)
The fact that most popular editors and IDEs (every one you mention) have VI/VIM plugins suggests otherwise.
It's (usually) not the editor itself that people find appealing. It's the key bindings. It's the fact that you can navigate around a file without reaching for the mouse.
Being at a company where most people do not use Vim definitely has caused a great deal of consternation and discussion about why I use Vim, and why I don't use a "real" IDE.
It becomes a hot topic of discussion without my wanting or really worrying about what other people are using.
I think the comparison to Veganism is a good one--- people think it's a flex, when in reality I just like it and it helps me get my work done.
I think they are just being posers. When we compare the efficiency of debugging (p. ex.) it is clear who can find the problem fast.
Today if I'm conducting an interview and the someone tries to convince me he/she is a good programmer and just use vi/vim, I need to rethink my decision because it can compromise the whole project. I'm not saying they are not good, but having the capability of fast debugging and solving problems fast is crucial sometimes and is part of the whole package.
I was that kind of person someday and I understand the feeling.
But for devops, vim or emacs are the all-in-hands tool and everyday editor, just because they are available in everywhere and work very well on terminal mode.
Interesting comment. I've been programming for more than 25 years. Have used stuff like GWBASIC, TurboPascal/C , fancy ide like VisualStudio, Eclipse, Netbeans and the new kids like atom or vscode. I even used DDD at some point.
Line debugging becomes less and less valuable as you become more mature in you dev career. Sometimes you have a race condition bug, some times the target architecture just doesn't provide it (devkitpro/devkitarm or embedded) and sometimes bugs that are evident in production just cannot be replicated in your debugging environment.
In my experience it is more valuable to improve skills of building mental models of the system at hand, get effective with console logging for key info and troubleshoot issues that way.
>some times the target architecture just doesn't provide it (devkitpro/devkitarm or embedded) and sometimes bugs that are evident in production just cannot be replicated in your debugging environment.
It happens, yeah. What mostly happens is that 99% of software development has debuggers available and that they are infinitely better and more useful when resolving issues. Printing, then realizing you don't have enough info, chaning your code, recompiling, printing, etc, is just not good software development practices.
Live with your constraints when you have no other choice. Use the tools that have been a standard in the industry when they are available to you.
I think you should evaluate candidates based on the skill/knowledge they show in the interview and trust that if that is up to par, then they will be competent to choose the tools that work best for them.
Disappointed the article went straight from punch cards to video terminals without mentioning teletypes.
> Having that thing show up on computers in those days was pretty tricky, and some considered it a resource hog.
Well in the 60's and 70's, you didn't necessarily even have a display, you might be using a physical teletype. `ed` is built for that.
Even when you had a display, it could be slow. The VT05 from 1970, only went up to 2400 baud. And if you were using a modem back then I think you were definitely most likely connected at 300 baud or below.
Watching it for the first time is what finally made ed click for me.
And yes, I was disappointed that the author clearly didn't understand why ed has the UI it does. It's about the teletype, not the computational cost of having a WYSIWIG UI.
I desperately want to set up a teletype on my modern desktop - there’s just something so awesome about electromechanical interfaces with a lot more mechanical than electro.
Yeah that video is all kinds of amazing. I also got lost down a several hour rabbit hole watching the guy and his buddies bring up an AGC and perform a simulated lunar landing with it. Thank you for sharing!
Or the display might be a single line of 16-segment LEDs for interacting with the machine, and "output" was on paper. Another reason to keep the visuals to a minimum.
Does anyone have a good video comparing vim speed coding vs vscode using built in editor features?
I’ve been using vscode for years and the YouTube videos that demo vim features are shallow (like how to enter a blank line - really?). I can do the same thing I have seen in vim videos without memorizing a bunch of strange key bindings all while being able to edit code instantly without changing modes.
I would love to see a fair comparison between someone using vim at 100% and someone using vscode at 100%.
Of course some vscode shortcuts might not be fair (like F12 to jump to definition, F2 to rename every usage, etc.)
But even in raw editing:
With vscode, I can do multi-line editing, I can navigate quickly, jump to specific words, etc all very fast.
If there is no video like this, would anyone be interested in a race?
There's too many little things to mention, they do all add up to be quite significant in the course of programming.
Here's a tiny sample of some stuff I use constantly:
Move cursor forward word at a time: w ignoring punctuation: W reverse: b B
Move cursor to next occurrence of character Z: fZ reverse: FZ
Delete forward to next occurrence of character Z: dfZ reverse: dFZ
Change forward to next occurrence of character Z: cfZ reverse: cFZ (like delete but leaves in insert mode afterwards)
Repeat latest edit from current cursor position: .
A lot of the vi commands are composable, as illustrated to some extent above.
To search for say the next line starting with void: /^void
To delete from the current line up to the next line starting with void: d/^void
Note the similarity to dfZ/fZ from above, it's not 100% consistent but most times you can take a chance composing things as you'd expect and things work correctly.
There are far more sophisticated things too of course, but I'm not writing a vim tutorial in an HN comment.
You can do things like rename a function while rearranging its arguments either file-wide, or on a number of lines, or on an interactively selected visual region, or a section selected similar to d/^void... I presume other editors have such capabilities, but I'm most familiar with vim. In vim the actual renaming and rearranging is done using a regular expression containing backreferences:
You may constrain that to a subset of lines a variety of ways, and on top of that can suffix a 'c' on the end of the substitution regexp to make it conditional and you'll get a chance to interactively yay/nay the substitution at every match in the considered lines. The conditional suffix is a godsend as it lets you be fast and sloppy with your regexps and just skip the false positives.
Honestly, I can do almost all of these things with any standard editor as well, with standard shortcuts.
The ones I can't do directly, I can do via Search/Replace
functionality that is also standard in most modern editors.
Your example about refactoring a function by using text editing capabilities is actually pretty bad unless you mean Vim can actually parse your programming language and perform the refactoring over all your code-base (not just a single file), like any IDE will do.
This list you gave me just convinced me I don't need Vim.
Here's the real question - So you are convinced you don't need Vim, right? Why are you on this thread?
No one's saying vim is superior. However, you need to have an open mind to understand the alternatives.
It's not like Vim is a paid product and by you not using it, Vim is going to die out soon or anything.
If you dont' like it, great? You are happy with the alternative, great. You seem like you just want to deliberately start an argument and then prove you are right, but why?
I am in this thread because this is not a thread about how Vim is great, it's a thread about how Vim became popular, which I honestly don't understand in a day and age where modes are completely unnecessary. I see lots of happy Vim users telling the rest of us how they are so happy with Vim and they can't understand how anyone can do anything without it... so I thought I should point out I feel extremely productive on any non-mode text editor (all my shortcuts work even in this HN editor, on a browser, in Word, basically anywhere except old editors like Vim). Been programming for nearly 2 decades now and even when I started, I thought Vim was a tool from a time when we didn't have Ctrl and Arrow keys and we already had better alternatives.
At this point, I feel like "I use Vim" is like "BTW I use Arch", said usually with an air of superiority as if choosing "the hard way" was somehow smart.
which I honestly don't understand in a day and age where modes are completely unnecessary.
Modes are everywhere. My microwave has a defrost mode. Cars have reverse mode. Pill bottles have modes where the bottle has to be held differently to open it.
Modelessness isn't all it's cracked up to be.
I’ve used many editors on the Mac—BBEdit, SubEthaEdit, Chocolate, TextMate, TextWrangler and a few more obscure ones.
I switched to Vim and haven't looked back nearly 10 years ago because the "modeless" editors had limitations and issues I didn't like.
I used Emacs when I worked at MIT because that's what everyone used, but it never took for me when I had to use Unix.
What the author didn't mention is that when Ruby on Rails was the new hotness, so many of the leaders in that movement were Mac users, on TextMate. But when TextMate went into limbo, and then eventually died, that tribe needed a new editor and they essentially all moved to Vim.
Many of the early Rails videos were done on Vim; they were quite influential.
I wanted an editor I wouldn't outgrow in a few months and Vim fit the bill nicely.
And to this day, I feel like I'm pretty proficient with Vim but I also know I'm using like 10-15% of what Vim can do and it's nice to know all that capability is there for when I need it.
So if I understand you correctly you're angry that people choose to work in a way that you think is unnecessary and that they're just doing it to show off.
I can't speak for other vim users but I think it's pretty obvious to us how other users work without vim and we know you can be productive without it.
Personally I make a point of not telling people to learn vim but equally I think, for example, not having a shortcut to repeat a complex visual selection is a pain.
I never feel the need to enter a thread about IDEs and point out this missing feature (especially if it's a program I don't actually know well and that might not be the case).
However I often see people that don't know vim well make statements like "vim can't do x" without actually checking if that's true.
Then we look "superior" when we point out how to do it in vim.
It's hard to win because your argument sounds like an emotional one.
To win what? This is not a contest or even a debate where one point of view may prevail... we're just expressing our opinions about Vim and its alternatives here. Obviously, if you like Vim, great! But it seems to me you're the emotional one if you find it necessary to question anyone pointing out they believe Vim is not a good tool at all (it promotes modals, which should have died as soon as they became unnecessary due to hardware improvements as they are objectively harder to use) and wondering why it's still somewhat popular.
I use vim as a boring config editor in terminals. I don't think it's the best editor by a long shot and even something as basic as Atom is more productive for code editing for me.
The idea of customizing your vim setup for maximum productivity doesn't appeal to me. It always ended up in a mess and over ssh it's pointless.
So I am a fan of vim and have used it on and off for 15 years at this point. I generally use IDEs or VSCode these days instead for writing code. Here's my take.
I think the popularity of learning vim might be similar to what jiggawatts mentions as the 'perception of speed', especially for tools in the UNIX world, as well as being 'the hard way' like you mention. But I think there is value in learning how to use vim. I see the advantages of learning vim are programming language agnostic. Vim is focused around words and text, treating them as objects, and creating a mental map of keystrokes to modify those objects. I think it's somewhat analogous to typists that hunt-and-peck vs touch typists. Opens up a lot of productivity, but it's definitely not needed to be a writer.
I agree vim has many limitations. It has a not so great language for scripting, no out of the box setup for stuff like refactoring or renaming symbols in your codebase, GUI feels like a second class citizen (IMO, compared to the terminal version). In a lot of ways, it might not hold a candle to the likes of VSCode, Atom, Visual Studio, XCode, IntelliJ, Eclipse, etc.
The nice thing is that you could add a vim-like plugin to any of those IDEs/editors to match the spirit of vim, at least in terms of navigation. It's not like you need to stay in vim to reap the benefits of the mental model.
I think that's where a lot of the power and appeal of vim is. Vim is still drawing a new generation of programmers, artists, and hobbyists to learn this strange text editor, with its unique but powerful way of interacting with text.
The parent described only a fraction of what vim can do. The notion of text objects and combining them with plugins makes vim much more powerful. Even without plugins mastering vim makes writing code quite natural.
vscode has regex find replace, but I don’t use it very often. It does show every match highlighted in the current file while entering the find value, which is nice.
It does the same for multi files if needed and gives a nice preview of every change.
Word navigation I use a great deal (especially with multi-cursor editing). Ctrl+left/right jumps words, home, end to begin end of line.
Ctrl+f Z Enter would go to next Z value. (Which I don’t use, because I don’t think in partial words much, but rather jump to mouse if I need to navigate far)
That’s probably where I could gain in using that instead of going to the mouse every time.
Ctrl+arrow is almost as bad as going to the mouse. The thing with vim is you rarely have to leave the home row.
Some other random things I use constantly (I am not the person you're replying to):
C — replace to the end of the line
xp — swap two characters (which I have to use more frequently than I'm willing to admit.)
ci( — replace everything in brackets (like the arguments of a function, this also works with " or ' for strings, { for blocks of code, and so on). The cursor doesn't have to be inside the brackets, it'll jump to the nearest match.
:earlier 10m — time traveling, which comes in handy between commits or with config files, especially if you configure vim to write persistent change history. What did this file look like a month ago? Oh yeah, :earlier 30d
. — repeat the previous command (this is much bigger than it sounds, as it allows you to repeat the same complex manipulation on different data in situations where you can't use multi-cursor, but which don't warrant building a whole macro.)
A ton of custom filetype- and mode-dependent <leader>-based bindings (which is the spacebar in my case). space-space to jump to definition, space-f to reformat the file, that sort of stuff. This can probably be done in vscode.
If you're really interested, there are tons of vim videos on youtube made by real vim pros. I am very far from being one. The best for me are live coding sessions where vim usage is demonstrated by doing the real work, not on some toy examples.
> :earlier 10m — time traveling, which comes in handy between commits or with config files, especially if you configure vim to write persistent change history. What did this file look like a month ago? Oh yeah, :earlier 30d
Another trick to my bag, that's why I absolutely love these threads about Vim.
On a Mac at least, ctrl+n/p/b/f/a/e all navigate text without reaching for the arrows, with the added benefit they work in every application. I quit vim because I prefer using a smaller but universal set of navigation that works everywhere from Xcode to VS code to the terminal or typing in Chrome.
Ctrl-arrows is not the same thing as vim’s wordwise movement. If you need to go 5 words forward, it’s 5w ; if you want to capitalize the next 3 words, gU3w ; the point is composability, not a single operation. Same goes for f.
I guess I, and maybe other non-vim users, just don't see much use in the composability. From many examples I've seen in this thread, the only one I found truly interesting was the branching undo feature.
For most features, the advantage seems very small, as the use-case is so rare, or it's not the limiting factor anyways.
But this is very limited to my experience. I am pretty sure, if I already knew those things, I would value that investment the same way the vim users do in the vim threads. But for now, it seems to me, that the investment is not worth the payoff and I am better off learning something else.
I use the vim plugin inside of VSCode and it's perfect for me. I would never go back to just VIM, or just an IDE. but my best use case for vim modes is stuff like: [c]hange [i]nside ["], where wherever your cursor inside inside of a "string", you can just press ci" and can immediately start typing a new string to fill it. And then this same thing can be changed to ci{ to change everything in {} to change a function, or ci( to change a function's paramaters, etc.
Then theres stuff like [c]hange un[t]ill [x], to change everything up to a certain character.
or [y]ank [i]nside ["], to 'yank' (copy) the text inside of a string and be able to paste it immediately anywhere I want to. It's verbs and sentences that you're writing in VIM modes.
Do modern editors have these kinds of keyboard shortcuts?
In general I think vim users are extremely bad at explaining why vim modes are so good, as I never use 5w. Am I really going to count how many words ahead I have to go? No, i'll just press [f]ind char to the word I have to go to.
The biggest thing about vim is that it doesn't make you more efficient or faster, it just eliminates the time you have to think about how to edit text once you internalize it, which I know doesn't sound likely because the keybindings are so strange. But know that I've learned it, i genuinely don't think about it, and every time I'm not in VIM and have to move my mouse and click on a character I feel like I lose my train of thought of where I was in the code
Actually I never wondered if there were shortcuts for those, so your response prompted me to check the keymap of m PyCharm. There definetly are many extended ones, but doesn't seem to cover all of that and are not as composeable.
> But know that I've learned it, i genuinely don't think about it, and every time I'm not in VIM and have to move my mouse and click on a character I feel like I lose my train of thought of where I was in the code
I believe that, so please believe me when I tell you that I just have navigation with the mouse and other shortcuts internalised for many things. I'm not really actively thinking about it either.
Thanks for taking the time to share your thoughts!
> I believe that, so please believe me when I tell you that I just have navigation with the mouse and other shortcuts internalised for many things.
Definitely! I just want to provide an actual reason for why VIM is great as people who are very into it are the worst at telling you why it's good.
It's usually, "well if you spend 3 months tinkering with configurations and plugins, you can basically have most of the features an IDE has out-of-the-box!" which misses the entire damn point of vim.
Also it's great because if you're ever ssh'ing into servers, you can be confident that you can be close to as productive editing files there as you are in your IDE, which I find very re-assuring. But as it is right now, I don't see a reason why anyone should switch to vim unless they enjoy the act of learning it and want to get some of the cool composability features, which are just fun to use and learn
> Delete forward to next occurrence of character Z
How often do you really do things like this though? It seems like, sure you can do weird obscure things quicker in Vim, but only if you happen to remember how do to the weird obscure things, and it's only useful in weird obscure situations.
For 99% of tasks the built-in VSCode stuff does the job for me. Ctrl-D especially.
> How often do you really do things like this though?
All the time. Some examples:
* ct, : "change up to comma", useful for replacing a function argument.
* ya" : "yank around '"'", copy the string literal the cursor is currently inside.
* ci( : "change inside '('", useful for changing the condition in an "if" statement.
* da{ : "delete (i.e. cut) '{'-delimited block", useful when changing the structure of if/else blocks.
I agree that these commands may sound obscure, and many Vim users use the program for a long time without using them (I certainly did). But when you start using them, you find that these composable editing commands correspond really well to many of the logical editing actions you perform.
I don't use vim, but this feature seems mostly useful for deleting things within marking characters, such as " and ', which I do surprisingly often. (But not often enough to learn a shortcut to do it)
Not that specific example, but you'd really be surprised by how useful some of these things are. For example you can do a `di[` to delete everything inside an array. Or `ci"` to replace everything inside a string.
Its a simplified version of a problem from work a while ago where we had to generate ui from lots of csv files. The last dev on it was taking weeks, but with vim I was able to come in and finish the boilerplate instantly. (We were commited to non-dynamic ui at that point, I think I made the right play especially with how we ended up using it).
Vim is, in my opinion, inferior to an ide or a good text editor, but if you have it as a plugin you get the best of both worlds and vim suddenly can do... basically anything you can think of. Like here's putting a breakpoint on every line in a file
Ya, basically go up, grab number, go down, paste number, increment number, go down, repeat 50 times. Needed for generating xaml that had row and column #s from the csv, interestingly excel could gen the code too relatively quickly.
copy 10 lines from the current position into buffer q, go to the start of function jnk, copy 5 lines into buffer w, jump to line 10, paste contents of q, contents of w, and contents of q sequentially one after the other:
"q10yy /jnk "w5yy 10G "qp "wp "qp
now, go to the start of the document and indent the next 20 lines by 10 spaces:
0G .,+20s:^: :
ok great, now find JUNK and replace 'a1' with 'A1' in the 15 lines that follow:
/JUNK .,+15s/a1/A1/g
probably not as efficient for multi-file refactoring, but for raw 'drag race' style text munging, everything is there, loaded in muscle memory, and under the home row of your keyboard so you don't have to lift your hands at all.
Just thinking out loud how to do that in vscode for comparison:
- I don’t think repeating actions a specific number of times makes sense in most use cases. Counting 10 lines would take longer than doing shift up/down n times (which would be exact with feedback) to select the desired lines.
- Multiple Copy Paste buffers sounds interesting, I might look up a vscode extension for that. (Had a copy paste queue in Visual Studio but it would break sometimes and would lose something important).
- go to start of function jnk, there are many ways to do that in vscode. Ctrl+f jnk enter would be one.
- Goto start of document is Ctrl+Home
- Indent 20 lines by 10 spaces, could do Alt+PageDown, then up/down to get to the right place (without counting or caring that it is exactly 20 lines), then with multi-line insertions could space,tab, etc.
That operation would probably justify mouse usage though, in which you simply hold alt, drag ~20 columns/~10 cells and hit space - which itself would be faster than counting 20 lines.
- find junk: ctrl+f junk enter
- select 15 lines (shift+page down,up/down to adjust) I can preview I have selected the correct area, other possibilities to select current function, etc.
- Ctrl+h to replace, a1 tab A1 Alt+L Enter
- of course in most cases, I am renaming a symbol, so “F2 A 1 Enter“ would do
I think the reality is that counts are not known before hand, so being able to increment/decrement with visual feedback is perhaps faster than a miscount, but I’d have to see it to know.
Anyway, thanks for the detailed examples! I can certainly see how it would be powerful if committed to muscle memory, but even with vscode there are many shortcuts I don’t use because of formed habits.
I have a plug-in installed in vim and vscode (and ilellij) that provide me with relative line numbers in addition to absolute line numbers. So, the current active line might display "353" in the gutters for the 353rd line. Both the line above and below are 1. The next lines above and below are 2. And so on.
There is never any "counting lines". If I need line's number, I can do a quick addition/substraction in my head or j/k $offset to see the other line's absolute number.
I can do line-based operations a lot faster than shift-tapping or click-dragging, with exact precision because my editor has been customized to provide the data I need. Eventually you get pretty good at estimating line numbers and character columns too.
for line counting - indeed a good point and clearly required for the examples -
After time, eyballing this becomes a skill. For things that fit on a screen (~50 lines or so, give or take) I'm usually correct 1st time or within a few lines. I can check quickly by moving the cursor (20j to go down 20, 20k to go back, repeat if necessary to get the line count)
also as others have pointed out, I might not be doing the best/optimal thing for some of these, just some examples of how I do things that popped in my head :)
I find it interesting how we use vim so differently. I'd never type "10yy", I'd use "y9j". I never use "10G", I use ":10<CR>" (<CR> = enter for those not familiar). Similarly, "0G" is "gg" for me. Call me a notepad user, but that whole second snippet for me would be "ggV19j>" followed by "." until things lined up correctly. Similarly, the third would have been "V14j:s/a1/A1/g".
Nit pick: "q selects register q. A buffer is a different thing.
If the language uses curly braces to define blocks, it's easier: ciB. Parentheses are easy as well: cib.
Otherwise, I'm not sure there's a good solution currently. You can substitute by indentation with a plugin (https://github.com/kana/vim-textobj-indent/blob/master/doc/t...). For Lua, I usually do c/end<enter>.
I believe this is an area where treesitter can help, so I'm looking forward to Neovim's integration.
Highlighting the initial { of a function and then typing 'va}' ('v' for entering visual mode, and 'a}' moves to the matching close brace. Similar commands work the [], (), and <> pairs) selects the entire function body. From there, a regular s command will operate on the entire selected text.
There are things that vim does better. There are things that VS Code does better. There are things that Visual Studio does better. You can memorize all sorts of things about your particular editor of choice and you will be more efficient and effective in that editor.
If I wanted to cherry pick examples of what vim does better, I could start all of them with, "first ssh into a random server."
What makes vim great is that it has a tremendous number of features and is available nearly everywhere. Can VS Code do that?
If you’re on a new machine, you can grab your dotfile repo from wherever you keep it—like GitHub for example—and you’ve got your complete config, since there just text files. Takes 5 minutes.
But even plain vanilla Vim is more than enough for many tasks on a new Unix/Linux box.
Not if you use Emacs/evil. Tramp invalidates most of the "well, vim is available on all my remote servers, whereas Emacs never is". I just remote into a server from within Emacs.
Evil is also the best and most complete vim experience outside of vim.
For your use case there are a lot of ways to do that in Vim without using the multi cursor, here[0] is one thing I just recorded to show you a glimpse of what's possible with just a search and replace: I just find a pattern and replace it with a part of the same pattern.
Again, you can do everything here without using multicursors, just record a macro for one line and repeat with a count and you're set.
Now if you absolutely want the multicursor feature, there are more than one plugin[1][2] for that, but I never felt the urge to use multiple cursors in Vim.
There's a couple of ways you could tackle editing that depending on what your json looks like.
For example you could use the visual block mode (ctrl-v) and highlight to the end of the line using $ and then use A to edit the end of every line at the same time.
That works with lines of different length.
Or you could use a regex inside of a block selection.
Or there's a multi-cursor plugin available for the same approach as you're currently using in VSCode:
Jump to definition and rename every usage are really handled by the language server. Vim supports language servers quite well. I do both those commands in vim all the time. And vim complements them with (book)marks, return to last edit, etc.
Vim can jump to definitions and stuff too. It integrates with ctags. It can also do code completion and everything else. I have it bound to clang-format with ctrl-k.
Heard good things about it, but I'm on an endeavour to learn how to do things with Vanilla Vim first to avoid abusing my use of plug ins for things Vim can handle gracefully ootb.
Now you're the creator of autojump, I just want to say your software is definitely a time saver, especially with this https://github.com/fdw/ranger-autojump, keep up with the great work.
I'm with you with avoiding too many plugins. But LSP is not just another plugin, it's the standard for languages to implement IDE support. I find it hard to justify not using it if you're doing serious software development (depending on the language of course).
Thanks for the kind words on autojump :) I'm no longer involved with the project, but I feel the general idea is still relevant.
Between the awkward file navigation and the feeling of building my own editor from the ground up, I just never found it worthwhile to fully commit to Vim. So I work in VSCode in my day job.
What I did take from those efforts, though, was Vim's text navigation key bindings. They are a joy to use and most text editors have some sort of emulator for them. The beauty is in the chording, almost all of which maps to easily remembered mnemonics. Delete everything between quotes? Use di". Change curly brackets to square? Change surround, or cs{[. Once you've gotten used to switching between move and edit modes, you can layer these in bit by bit. At a certain point it becomes second nature and you do feel like you can edit code at the speed of thought. It's a powerful feeling.
> I can do the same thing I have seen in vim videos without memorizing a bunch of strange key bindings
you totally can! I could talk for a while about customization and ctags to address some other points you made but at the end of the day its a text editor, vim and vscode are both text editors. it sounds like you really like using vscode so you should stick with it, I really love vim and it works really well for me, and my boss loves using a near vanilla sublimetext 2 install. programming will never be about typing and editing speed but being comfortable with your development environment and hopefully even enjoying it is very important.
One vim hack I like is multi-line macro application. It's a good fallback in case, as I often forget the syntax for certain things. To facilitate this, I've remapped ctrl-space in visual line mode to apply my `q` macro to every selected line.
As an example, say I need to add a comma to a bunch of lines. I will record the macro on that line appending a comma to the end, visually select all of the other lines to copy the macro on, and then jam my hotkey to apply the macro.
It's often much quicker than reaching for a regex for short segments of code.
I've found keyboard-only vim is much slower than a mouse for editing papers, because the edits are often random-access and vim isn't great at that. You also can't use SyncTeX (which is amazing) without a mouse.
There's no point in comparing them, in my opinion. VS Code is a tool for programming; I would call it an IDE but I 'm not very familiar with the app. Vim is still "just an editor". You can still use it for programming (not just coding bash scripts), but that's making your life harder than it needs to be.
In my experience the amazing text editing features of vim are only very rarely useful in a software developer's work. I feel the same about multiline editing though.
And Vim has amazing text editing features, but severely lacking code editing features.
I started using emacs in the early 90s and got really into it during uni, studying CS a couple of years later. In mid 2000s I ended up in sysadmin work in a mixed Unix-environment (Tru64, AIX, Solaris, Linux) in a group where all other used (some Vi(m)-variant).
I tried to get work done with emacs but failed due to various special characters always getting mangled in different ways over different terminals on different platforms and after a couple of months I gave in and started using Vim instead.
I finally understood that Vim had two essential properties that other editors lacked in this case.
1) It works well in environments where special characters will get mangled in various ways over different platforms. As long as ESC works, vim will do the work just fine.
2) The modes makes it very reliable to use when you have to make specific operations in exact places in text-files. This alone should make it the goto editor for sysadmins where you often have to make just a few character changes to a configuration file and be sure you do not change anything else.
A third reason when starting the work was also that Vim came by default on all out platforms so we knew it existed there and it was a nightmare trying to get approval for extra packages to be installed, but the first two reasons are what keeps me coming back to Vim whenever I need to do some text-file surgery.
It's nice that ESC works but I also want : ex-mode to work as well. It's why I continue to use MacVim rather than Visual Studio Code. VSC's vim emulation is pretty good ... except for ex-mode and I use that a lot. So I go back to MacVim and stay there.
MacVim is a bit clunky but I've gotten used to it. I tried to get YouCompleteMe to work with it but failed (the plugin interfaces are ... complicated). I can't get function name syntax highlighting to work to my satisfaction but still I've stuck with MacVim.
Maybe VimR (gui for neovim) or neovim + VSC will work.
---
This works-ish. :s/this/that/ works but g/hello/p doesn't. But maybe it can. I'll investigate.
Think you still have to go to some trouble to activate but I'm pretty srue this is supported officially now. I think you just point the Vim extension to a Neovim binary, and you can have Ex commands and such using an actual Vim runtime.
For me it is being able to efficiently navigate a file without leaving the home row (Gotta learn touch typing first). Once you understand the commands follow a composable grammar it is really like a superpower for dancing around text.
„Go down 5 lines, move right two word, replace the contents of the brackets“. I don‘t use the actual editor all that often but have vim mode enabled in all my „real“ editors like VSCode or JetBrains Suite. I am often wondering how people do edit source efficiently without vim mode but I am too shy to ask.
Honestly, this stuff is not a bottleneck for me. The things that both emacs and vi do, and vi does a little better:
1) Supports more than basic text manipulations. Rectangle selection and deletion? Check. Regex operations? Execute shell command on selection and replace inline? Record a macro and execute N times? Modes? Stuff like that.
2) I know it really really well to the point I don't need to look anything up to use it.
3) Runs anywhere. Got a shell on the hard disk controller? It will be there.
Vi is better only at 3. Emacs 1-2, and I would say 3 partially compared to other visual editors that you sometimes can't run even if you tried.
I really don't care about the Lisp, or the home row stuff, or whatever. That falls under #2. As long as I memorize and get good at how some operation is done, and the effort is similar, I'm fine.
And then we get to #1, and pretty much all good editors today do well there.
I've been using vim for about 7 years and for me it's not so much about the efficiency as it is the pleasure of commanding (programming!) a powerful, wellmade tool.
This is the same for me, I very recently got over the hump, and finally am a proficient Vim-er! I never cared as much about the efficiency.
Not talked about enough, is the fact that Vim is simply fun. I simply enjoy typing with it. You’re right, it really is a pleasure, and it makes you think about programming differently.
It stimulates a part of my brain regular editors never did. It’s exciting to think about the best way to perform a series of actions, or learn a new command. Or brew up a quick macro to do something wild, no other editor could dream of!
And once the commands become second nature, you almost feel “at one” with the file you’re editing. I feel the fluidity that vim offers me lets me dedicate more cycles to the problem at hand.
I don't see it as a bottleneck, but focus. Not searching for the mouse or something or stretching fingers to Edit with Meta Alt Control and Shift etc. but fingers where they feel comfortable efficiently browsing the files.
Yes I hear that as well. IMHO most of the time is thinking but when I want to move stuff from my brain to my screen I prefer maximum bandwidth and not having to consciously think about it. To each their own I guess.
Totally. I also find that using it, I'm more willing to externalize my thought process, put code on the screen to reason about it and quickly scrap or modify it if it doesn't work.
I have been using VI(M) since the 80's and it's amazing how fast you can navigate in it when it's just deep muscle/neural memory. In fact if you asked me how to do some navigation in there, I actually could not tell you - but I could just do it.
I'm also someone who immediately installs a VI plugin into any IDE I use, as otherwise I'm lost.
IDEs and their editor key/control systems come and go, but VI(M) remains constant, and has done so (for me) for 35 years.
Look at the beginning of a target line, remember the number (takes up a slot in our limited short-term memory), switch to command mode, type the command.
vs
Hold/mash "down" button until cursor is there.
After watching a few vim coding screen-casts I have the impression that the second way is more popular in vim too.
TBH I think I almost never look at the line numbers in vi, but the alternative isn't always holding/mashing j.
I occasionally use a count (5j to move 5 lines down, especially good for moving ~4 lines at a time), sometimes use C-u/d, C-f/b, or H/L to scroll half a page up/down, a full page up/down, or move the cursor to the Highest/Lowest line on the screen (these are good for large movement. And you can use zz to recenter the cursor on the screen after H/L). But likely the most common vertical movement I use is curly brackets/braces to move a paragraph up/down.
In CUA editors to me the nicest shortcuts are Control[+Shift]+Backspace and Control[+Shift]+Arrow because they involve the editor understanding a basic construct of human language (words). Vi takes that to the next level.
Why? Just use the 'relativenumber' option and do 5j.
> the second way is more popular in vim too.
Maybe for moving down 5 lines, but (I hope) not for things like "replace the inside of the brackets with what's in my A register". Otherwise you're really better off using a different editor.
Contrary to popular techy opinion, short-term memory is not composed of hard, fixed "slots" that fill up and overflow. It's not like remembering one more byte of information will make a variable name fall out of your memory on the other end.
Besides, it might just as well become something you don't need to use memory for at all - just press Esc to make sure. If you're in command mode, nothing happens. If you're in insert mode, you've entered command mode.
If that was a genuine question, I have coworkers who just embraced their IDE shortcuts (IntelliJ and Eclipse can do all the things vim can with weirder shortcuts and no vim mode) or they use emacs / emacs-style shortcuts
I think it's a bit sad that the article completely fails to mention that Bram Moolenaar originally implemented vim on the Amiga. Actually this might have contributed to its popularity: back in 1991, Amigas were much more widespread than Unix boxes, and around the time Commodore went bust and the Amiga was no more, i imagine lots of developers migrated to then-new Linux rather than to the despised DOS/Windows, and took their preference for vim with them.
I know I'm going against the popular opinion here, but I have never observed anyone using either Vim or Emacs to outperform a competent IDE user, especially Visual Studio or IntelliJ.
I mean sure, if you think IDEs are just slow, expensive text editors with fewer keyboard shortcuts, then you'll be disappointed, but features like "navigate to any symbol by prefix", "find all usages", and "Ctrl-click to navigate to definition" have no comparable analogue in traditional text-focused, non-IDE editors.
Not to mention visual debuggers, not to mention remote debugging! The VS IntelliTrace feature alone is worth the cost of the entire IDE.
There's just nothing like any of this in Vim or Emacs.
I mean sure, if you futz around with plugins, you might be able to reproduce some small subset of these features, but then you'd have wasted more of your time tinkering with the editor than actually getting work done.
What I've noticed with a lot of tools that trace their origins to the UNIX world is the perception of speed. Typing many keys rapidly to trigger shortcuts feels like you're doing things faster than moving a mouse cursor and then clicking something, because there are more actions per second. However, objective tests show that even highly skilled users aren't as fast at completing high-level tasks as mouse-users.
One study that shocked me compared wall-clock development times for a moderately complex puzzle problem. It was designed so that most people would have to debug the program at least once or twice. Participants could use any development environment and language. Among the fastest solutions were users programming in F# and C# using Visual Studio, at roughly 30 minutes for F# and 60 minutes for C#. People programming in languages like C, C++, and Java in typical Vim/Emacs environments took days or weeks to solve the same problem! Days!
I've observed this effect with "command line jockeys" too, where they're absolutely convinced that bash is some power tool that nothing can hold a candle to, and then they take hours to solve some problem that's three clicks away in the GUI.
Visual Studio (not the Code version, though some will include that as well) is arguably once of the best IDEs ever created, so you are not wrong.
But often there are other issues. IntelliJ and its siblings can be very resource intensive -- many complain about the Clion launching your laptop fans, and its RAM usage, for example. And the UI of many IDEs has so much chrome everywhere, the UI often gets in the way for many. You can hide it and deal with it in some IDEs, but not all. There are just a lot of things to consider when selecting an IDE. For example, Emacs avy-jump is a really neat plugin (similar things for vim as well), but you'd have to work hard to configure an IDE for these kinds of features as well, so it goes both ways.
And btw -- Vim macros are perhaps one of the best text editing features ever created, and you can't find that so easy to use and powerful in any IDE.
And just the joy of actually editing text - which we do all day - arguably greater with the vim way of doing things. It just puts you in a certain zone.
There are things I do not do in vim, but they are few. For example, I've developed a few Android applications as a side project and I used netbeans for it. For rust, go, c, python, I've always used vim.
Of course, but is it as easy as two clicks in VSCode? There's so much setup to get it exactly the way you want in the terminal, where as it "just werkz" out of the box for VSCode. I'm a VIM user, but i use vim plugins inside of IDEs for this reason
> I know I'm going against the popular opinion here, but I have never observed anyone using either Vim or Emacs to outperform a competent IDE user, especially Visual Studio or IntelliJ.
> I mean sure, if you think IDEs are just slow, expensive text editors with fewer keyboard shortcuts, then you'll be disappointed, but features like "navigate to any symbol by prefix", "find all usages"
helm-projectile-ag (which I have bound to C-p s s) does this: C-p s s \bSYMBOL shows a list of all usages and enables me to navigate to any of them.
> "Ctrl-click to navigate to definition"
M-. does this in Emacs.
> Not to mention visual debuggers, not to mention remote debugging!
With SLIME I have a full remote REPL and debugger. And it runs in a GUI too …
> Visual Studio Live Share lets two people concurrently use the entire IDE at the same time, remotely
You could do this with multi-tty within Emacs, or with Screen or tmux, or with xpra. It would not be as ergonomic, I grant.
> There's just nothing like any of this in Vim or Emacs … I mean sure, if you futz around with plugins, you might be able to reproduce some small subset of these features, but then you'd have wasted more of your time tinkering with the editor than actually getting work done.
So, Emacs doesn’t have features it clearly has, but even if it does then somehow that is also bad? What is this, a game of ‘heads I win, tails you lose’?
Emacs looks like shit though, requires tons of time requiring to set it up and it still won't have the same insane functionality that Visual Studio does. Are you really trying to compare the two things? If you are then I would suggest it's because you haven't tried VS recently and realized the huge functionality it has...
I mean, does Emacs have a whole UI for handling unit tests which can be made to run automatically anytime code is changed? Does Emacs have contextual right click menus for almost any eventuality? Does Emacs have a visual browser for your code? Can you debug graphics pipelines (with previews of the output images) in Emacs? Does Emacs have built in code performance analysis tools? etc etc etc etc I could go on for ages here.
You try and compare Live Share with multi-tty? What a joke! Have you seen LiveShare and what it actually offers? Easy to use, amazing UI, you can see where the other person is clicking etc etc. The reason people use these tools is because they accessible, easy to use, and "just work."
This is the opposite of Emacs. Yes you can add "some" extra functionality by Frankensteining Emacs but it is about 1% of Visual Studio out of the box and convincing any of your co-workers to go through the pain of trying to emulate VS in Emacs is a fantasy, and then having to keep it updated and not broken... hahaha.
You're absolutely right that you pay a price for using Emacs, and that not having some awesome IDE features is part of that price.
Another part is having to look for and install the third-party modules that make it actually work well (most of them are not included in Emacs because of Stallman and the FSF being ideologues).
As you say, keeping it updated and not broken is yet another part of the price.
That said, it's clear from your comment that you have not given Emacs a serious try, at least not recently.
There's no reason you have to, but you probably shouldn't complain about it so vociferously if you haven't.
Right-click menus that cover most use cases (jump to def, find references, format code, etc) are absolutely a thing with lsp-mode (which is not too hard to set up itself - install it via the built-in package installation UI, install language servers, and tell emacs to use lsp-mode in programming languages).
There are unit testing modes that kick off tests automatically on changes and let you know if everything passed (or give you a list of failures when some tests didn't). I've not used those myself so I can't speak to their quality, but they definitely exist.
Further, these tools work for a wide array of languages, with the exact same interface for all of them (and an incredibly discoverable, extensible one).
Some of us like that a lot, as well as the comfort of having all the code to reproduce our setup directly to hand. I probably have several more decades in this game, so losing my environment to an IDE company going broke or getting bought is not a pleasant thought.
Tradeoffs, for sure, but with valid arguments for both sides.
My impression is that most people doesn't even bother to learn the editing part of the IDE properly, and use it mostly like Notepad. Visual Studio editor have ton of shortcuts for faster moving and selecting, Visual Studio Code is even better (vim plugin for most part just introduce modal editing and expose existing functionality), JetBrains IDEs are also full of text editing features. And yet, most people use only cursor keys, enter, backspace/delete and ctrl+x/c/v.
And another unpopular opinion: can we stop talking about hjkl cursor movement like the pinnacle of ergonomics? I get that people are used to that, but the only reason why that keys are chosen is because of that particular terminal used for making ed/vi. If moving the finger to reach movement left is so superior than anything else, default movement keys in games would be asdf, not wasd. hjkl is better than reaching for the arrow keys, but hardly ideal (I remapped arrows to caps lock + ijkl and to me it's way better)
Sorry but as someone that has done both C# in Visual Studio and embedded development in vim/gdb/UNIX, your claims do not hold up...
> have no comparable analogue in traditional text-focused, non-IDE editors.
The same features have been there in TUI editors for many, many years. There is nothing visual about the backend that handles those queries.
Whether the interface is easier to use or not is a different matter, but the features have been there for decades.
> Not to mention visual debuggers
Well, yes, visual debuggers are better with a GUI, that is obvious.
> not to mention remote debugging!
Remote debugging is very common. What you are thinking of is visual ones.
> However, objective tests show that even highly skilled users aren't as fast at completing high-level tasks as mouse-users.
Citation needed.
Blender, for instance, is praised by artists for its hard modeling productivity thanks to all the shortcuts.
A few years ago when I worked in VS, I used all kinds of shortcuts. It does not matter that the tool has a GUI or not to make the keyboard useful. It is orthogonal.
> took days or weeks to solve the same problem! Days!
That is just nonsense. There is no way one takes days/weeks to "debug" something that takes 30 minutes in another general purpose language.
Either the task could be trivially solved using the .NET standard library and not the others (which makes it incomparable), or they picked up participants with no clue in the other languages.
The debugger or the GUI/TUI distinctions have nothing to do with that. A visual debugger is most useful when dealing with very big code bases that you did not write yourself. For a programming puzzle that fits in 100 lines, a visual debugger is irrelevant unless you are new to programming.
Right, but coding is just one specific use of vim. Vim is a tool for a world where everything is a text file, eg:
- focused mode essay writing
- editing ~/.config/thing.json
- formatting a shopping list
- cleaning up scanned text from a PDF into markdown
- opening an encrypted password file and adding your home insurance renewal details
- writing up notes on a job contract
...and that’s just two hours into my day. Vim is general purpose. IDE usage isn’t mutually exclusive. When I need API aware typeaheads then I also reach for REPL.it.
Note some of the Java solutions were over 40 hours, and many are over 8 (one working day)
The version I saw was informal, and included F# and C#. I remember that F# was roughly twice as fast as C#.
I don't know F# but a friend of mine does, and we both solved the sample problem. He did it in under half an hour. It took me just over an hour, but I could have done it in about 45 minutes easily except that I had (embarrassingly) misread the problem statement and wasted a bit of time.
I used Visual Studio's debugger twice, and that did actually help a lot to get the problem solved quickly.
People who are really good at Vim and C remind me of someone who is really good at using a shovel. As impressive it is to watch them work, they can't compete with a backhoe.
I'm a big user of vim and use the vim plugins in whatever IDE I'm using. But I have to say I don't find this sort of argument very compelling:
> You can share Vim, Emacs, and your entire terminal with other engineers using Tmux or Screen.
I've needed to do that maybe once. People aren't usually very proficient with tmux/screen anyway, and clearly even less with your flavor of emacs or your vim setup. VSCode live share does that too, but whoever you share with will have their own plugins (+ you can share servers, terminals, etc)
> You can navigate to any symbol by prefix in Vim using regex
Any IDE has navigation by symbol built-in, and it's usually faster than typing regexes
> You can "find all usages" via :Ag whatever-you-are-looking-for
Not true, :Ag will find occurrences not usages, it's not aware of the AST (that I know of). IDEs have specific language-aware functionalities like "find implementations", "find declarations", "find usages"...
---
I'm aware these were just example of course and I'm sure there's things that vim does better, but the only real value I got from vim compared to other editors is the text-editing model that's noticeably faster when you're proficient at it
Ever year or so I look at the nice sugar that things like VScode or other IDEs have and think "it has vim mode, those nice things would be good to have" - autocomplete, things like that. So I try the IDE and I get so tired of _in the way_ it gets that I just go back to vanilla Vim.
Then I think "maybe I'll try these IDE like plugins for Vim" and get so frustrated by the Vim plugin system that its back to vanilla Vim pretty quickly.
I was wondering what language do you code in? I am a proficient Vim user but the more I use VScode for writing Python code, the harder it gets for me to justify using Vim for serious development.
If you use the right plugins + lsp, there's nothing you can do in vscode that you can't do in vim. Just requires a lot more upfront work, but you can check the config into a git repo.
The problem is finding the right plugins, but it doesn't require that much time (at least in Linux/Mac; Windows may be a different experience).
I use "IDE features" when writing Scala: vim-plug first, then vim-lsc + metals. The configuration of lsc is trivial (as in you can copy an example of less than 10 lines).
After using this for a while, I replicated the same experience in Python with python-language-server (I install it with pip --user), and it was matter of 5 minutes to setup. Before this I was using syntastic + ctags, and that required much more work.
May be is more work than getting the same functionality in VSCode, but it doesn't look a lot of work to me.
What I want so badly is real vim with an easy and expansive plugin system. I get by okay with neovim + Plug, but there's still more friction than I'd like. Bought the Oni2 early access because it looks promising, but its not quite there yet.
Regarding the picture of the woman standing next to the pile of punch-cards which is, annoyingly, uncredited, I have found it credited in this article [1] as:
> Programmer standing next to the SAGE computer's control program
> Image courtesy the Computer History Museum and the MITRE Corporation
I really need to show that picture to my in-laws. They met while working at MITRE during that era, and there's an excellent chance they knew that woman.
We also need to understand that a subset of vi features is part of the POSIX standard, so any POSIX system will need to have "vi". vim is the logical choice there.
So as a result vim has become the reference implementation for the POSIX vi featureset.
In my opinion, the best feature of Vi(m) is its ubiquity.
Also, it is fast and reliable.
That said, I never bothered learning many commands, only the very basic ones, I spend much more time thinking than typing anyway and I always felt the productivity gains to be marginal.
Something I've come to rediscover is how good vi/vim is on a slow network connection. Our sharp networking team route me from London to Sydney so I can remote back to my London PC.
Seeing what you type several seconds after you typed it is reminiscent of the 90s and dial up connections.
Having familiar vi keybindings in so many applications these days has been a productivity saver.
One editor which used to be great at this is sam, which was explicitly designed to work across slow links, by being split into a frontend running locally, and a backend being run on the target host: http://sam.cat-v.org
I've been using Vim more and more in the past few months, but I still use VS Code primarily for a lot of my work. At work, I do a lot of Node/TS stuff, so VS Code just offers a whole wealth of tools that I'm already familiar with. I'm sure I could pimp out Vim to do it just as well, if not better, but I still enjoy VS Code.
Where Vim shines for me is for creating and editing small files. I use vim for my journal, quick edits, and data wrangling when I need to get something into a nicer form (most often scraping links to pipe somewhere else). It's a great interface for editing temporary data.
Also, knowing Vim if you ever need to SSH into a remote machine is a must in my eyes. Nano feels sluggish once you get a feel for Vim, and, as the article mentions, you can fine Vim almost everywhere you go.
Why not use one of the many publicly-available add-ons that add Vim bindings to VS Code? Pretty much every IDE has at least one of those - as an Emacs person, I envy it.
Not quite, or maybe I'm the one not doing things the right way, when I tried to make VsCode behave like Spacemacs there was always these annoying things where you'll have the feeling that you're better off using the mouse: for example when you're editing, you can't close the sidebar without focusing it and firing Ctrl+E, I eventually discovered an emulation made by a bunch of people[0], it was great, but for things like Git, I still needed the mouse whereas in Spacemacs you can use the excellent Magit
which is entirely keyboard focused.
Not true. VSCode lacks some very fundamental functionality, like proper (non-linear) undo and the vim plugin basically does not support any ex commands (other than s, which works different as well). Having said that, I think the VSCode vim plugin gives a quite good experience overall.
I started using vi in 1986, switched to vim and (mainly) emacs in the 90s. My setup now is emacs for local editing, vim for sudo vi system.config.files and when I ssh to a server.
Actually vim had a larger share of users back then because there were not many other editors for UNIX and Linux. There are probably more vim users now but even on Linux I see many more people using VS Code. The problem they have is editing files when they ssh into a server. I usually suggest nano. Not many of them notice and understand the two lines menu at the bottom of the screen.
Vi (and ed) are the only text editors required to be included in the POSIX spec. A base Unix (and most Linux) installs will have some version of vi or vim installed by default.
If I'm working on someone else's box this pretty much guarantees I can edit files with my basic vi knowledge without having to install a different editor.
That's why I learned vi initially years ago, because I was told it was the only editor that would always be available anywhere you went. I only ever use it in ssh sessions these days, but I still feel like learning how to use it has paid off many times.
I was playing with Haiku recently and was surprised that vi or vim wasn't included in its base install. Granted, Haiku (like BeOS before it) doesn't ever claim to be a Unix-like or POSIX-compliant system, but I found the CLI environment to be very Unix-like overall. I guess it's a testament to the ubiquity of vi that it never occurred to me that it wouldn't be there. (If anyone's curious, emacs is also absent but nano is there.)
i tried to switch to emacs+evil, but i can't bring myself to do it. partly because I'd have to invest a lot of time in getting an equivalently productive environment, but partly because of the following
1. vi is everywhere, and...
2. vi with no plugins is still super powerful, which is helpful on random hosts / coworker's machines / basically anywhere, and...
3. since vi is still so powerful out of the box, i only need a few lightweight plugins to close the loop and make the most powerful editor i can imagine needing. 99% of my plugin usage is fzf and ale w/lsp, which are arguably two very powerful plugins, but the cognitive overhead is very low, and at least among peers my editor doesn't seem to be slowing me down at all
i would also pose the controversial opinion/hot take that using a less "powerful" (non-IDE) editor helps you write better code. humans can only fit so much into their working memory at a time. vim doesn't really let me do crazy refactors or jump through endless chains of class hierarchies (well, with lsp it can, but...). compared to my eclipse/intellij days (and codebases worked on by other people using those tools) i am forced to tame complexity by defining good module boundaries and abstraction barriers.
to your vimrc and you're set, you can recursively :find pretty much anything in the folder where you opened Vim and you can even go fuzzy, for how it works in practice: https://youtu.be/XA2WjJbmmoM?t=493
I’ve been using Vim professionally for like ten years now and I can’t tell you what benefits do I get out it exactly. I still use a mouse and I don’t see what’s so bad about it.the whole home row argument has never been convincing.
This is like someone saying they've used a DSLR professionally for a decade and couldn't say what benefits they get out of it over a point and shoot because they've never done anything other than leave it in automatic mode.
You owe it to yourself to explore and embrace the power of your tools as a professional.
Vi(m) in particular requires a deliberate effort from the user to learn its features, because of how it stays out of the way by design. It's not trying to be discoverable at the expense of experienced users.
Decades ago I tutored someone taking a C++ course who claimed to know vi and insisted on using it for the sessions. They knew how to use vi enough to be a notepad replacement, it was brutal to watch how much time they wasted neglecting to use any of vi's features at their fingertips. If you're navigating with a mouse or arrow keys, and treating vi as no more capable than notepad, you're not really using vi.
I’m pretty good at using vim, There’s really nothing I don’t know, and I’ve watched tons of courses and read tons of tutorials. I got my own vimrc like plenty of people. But People still use macvim, and hit Apple S, and Use the mouse, I’m hardly the only one. See Yehudas “everyone who tried to teach me to use vim was wrong”
When I was younger I cared more about it, but it’s all just yak shaving.
What there isn’t are obvious benefits to keeping your fingers in the home row, just vastly overhyped anecdotes.
By the way expert photographers will tell you that it’s not about the tools and that today’s phones are good enough.
That’s one of the things that are annoying, I’m the dumb one for putting a dissenting opinion, but no one is willing to explain why using the mouse is worse, and definitely not in a way that satisfies me
Hey just wanna let you know that I'm a fellow Vim user that uses the mouse for practically everything. I like using Vim for editing, but my brain still likes to do the "context switch" where I dig into menus and such.
If you’ve been using Vim for 10 years, and still use the mouse, then you haven’t really been taking advantage of the power of Vim. Perhaps that’s why you don’t see much personal benefit?
No, I’ve been posting here for that long too. I haven’t been living under a rock. I got my own vimrc and everything, it’s just not that useful in practice.
I really like how Vim is set up, even if I don't personally use the home row stuff. I just like the stability of the interface, its simplicity, and performance especially. I used to get really obsessed with editor stuff, then I realized I was wasting my time and that Vim was already installed on every machine - no additional install ever needed to set up the environment. I usually only ever add one or two lines to my vimrc (jj -> Esc). I like that it just works.
If I ever need to do refactoring I'll download CLion and get the engine running and fans spinning. But I do more debugging and reading code than refactoring it.
But just installing VSCode is simple too and in practice, it’s universal. I feel like people are self handicapping, specifically because the bottleneck in development is understanding, and not input speed.
If I was to say what do I like about Vim is the modal interface, and really because to me if feels right, I cant say that it’s objectively better
> What I am trying to say that vim is an effort of over half a century of good idea accumulation, putting lots of effort into being backward compatible.
I wonder what Vi(m) would be like if it were redesigned from scratch.
I hear good things about https://kakoune.org/. But I have 20 years of muscle memory for vi keybindings, and they're well-established enough that you can even use them in other editors like VSCode. So I'm wary of training my fingers to do something else that only works in one editor.
I've been loving vis¹, a hybrid between traditional vi and sam², a text editor Rob Pike designed from close to scratch.
(Edit) I learned vim a little bit over a year ago, switched to neovim soon after, tried kakuone for a few days and didn't like losing so much muscle memory because of the verb-noun order reversal, switched to vis a few months ago and don't plan to switch back.
Vi came about before CUA. If I was to design it nowadays I'd use 'c' for copy in normal mode, 'ctrl-c' for copy in insert mode, and keep that pattern as far as practical to ease the learning curve for people new to the editor.
I really want to give spacemacs a try, but unfortunately I've just been using traditional emacs for far too long. vi does seem to have a much better editing model than emacs. The tools Emacs has for buffer navigation and editing have always struct me as incredibly primitive.
I've recently blown away my several years old custom Emacs config and started over with vanilla Doom Emacs (it's supposedly a faster version of Spacemacs, but I don't really know, I just took a stab and grabbed one of them). I spent a weekend doing some VIM tutorials and writing down common key strokes of things I do all the time, and then on a Monday, it was all VIM navigation. A lot of your regular Emacs meta-stuff will still work, and for that, you can slowly start replacing with the spacebar-b key stroke for your buffer management, spacebar-p for projectile, etc....
There's still some things I like better about Emacs navigation and there's a lot I like about VIM navigation. I prefer Emacs crtl-a and ctrl-e for navigating to front and end of the line (instead of $ and ^, which is an awkward shift+number key on my keyboard). However, in Doom Emacs (likely Spacemacs too since I believe they both support Evil-mod) if you're in Insert Mode, most of your old Emacs navigation will still work, so this makes it a decent crutch for transitioning.
AFAIK it still tries to stay mostly compatible with regards to how it is controlled, doesn't it? So while the internals are perhaps new, the frontend is not.
Kakoune is definitely an attempt at redoing the vim concept from scratch. I spent a few weeks trying it out and attempting to get used to it. Ultimately, I came away from it feeling disappointed.
I think the basic premise of multiple cursors editing as a preferred model (which is what Kakoune does) is flawed. Why? Because large-scale scale changes are the exception, not the rule. By emphasizing multiple cursors, Kakoune actively makes it harder to do the normal thing people do in a text editor: jump around a file and make specific edits to individual lines. Instead, a bunch of normal movement commands (such as forward and backward search) leave extra cursors in your wake, forcing you to press an extra key to dismiss them otherwise you'll get erroneous edits that might not even be visible from where you are in the buffer. This is not a good thing.
The other basic premise that Kakoune addresses (that vim commands lack visual feedback) is not even an issue for experienced vim users who type commands quickly from muscle memory. The edits happen when the command finishes and you don't get distracted by intermediate results. For global substitution, you can always append the `c` flag to add a confirmation prompt to each substitution. That alone obviates much of the motivation for Kakoune's model.
I switched to kakoune from vim in early 2020, and I really like it (previously: emacs 1994-2004, vim 2004-2020). It's worth prefacing what follows by saying that I heavily relied on the visual selection features in vim.
kakoune provides a limited orthogonal toolset that composes extremely well. After a week using kakoune I felt at least as confident with its command language as I did with vim's after years of use. Aside from a few vim plugins that were super helpful, I didn't miss anything after transitioning, except for the 'R' command (and to a lesser extent proper integration between the 'r' and '.' commands).
I worried that kakoune's multiple selection paradigm wouldn't scale well, that it wouldn't be routinely useful, etc. On the contrary, I use multiple selections heavily, often as a more ergonomic alternative to recorded macros, constantly for rectangle-based operations (whether multi-line editing, indenting, ASCII art creation, whatever).
Oh, for you tmux lovers out there, kakoune integrates amazingly well. All of its multi-window functionality directly uses tmux panes, with a server application (think emacs-server) tying everything together.
In terms of ecosystem, vim is much richer. But kakoune is a practical, beautifully designed tool.
Could you comment specifically on this part of the comment you replied to?
> Kakoune actively makes it harder to do the normal thing people do in a text editor: jump around a file and make specific edits to individual lines. Instead, a bunch of normal movement commands (such as forward and backward search) leave extra cursors in your wake, forcing you to press an extra key to dismiss them otherwise you'll get erroneous edits
Do you find that's the case? If so, how do you deal with it? Just remember to dismiss the extra cursors?
It's quite common for the selection created by motion to have immediate subsequent use. I do use the ';' or ' ' commands to clear the selection or end multi-selection, but typically only once per major operation. On top of that, it is common to start some new editing sequence which automatically resets or extends the selection in a natural way.
Multiple selection has surprised me in its usefulness. It took a bit to get used to multi-step operations (select, then move/expand/match, then modify, etc.), but the beauty of this is that it's possible to incrementally undo these steps, unlike having to get the whole thing right in one go in vim. I find myself using regex captures in multiple selection -- another example of how I confidently use basic kakoune functionality where I used to rely on recorded macros in vim.
I'm really happy to hear that kakoune works for me. Perhaps I just don't understand it. Or perhaps I'm reliant on a different subset of vim's features than you were and my chosen subset doesn't map as well onto kakoune.
Most of what I do in vim is now so heavily ingrained in muscle memory that I just don't think, I see the text change to what I want it to be. Perhaps that's too hard of a habit to break for me.
If you stuck with it long enough do you think the multiple cursors would have given you an increase in productivity over vim? Like maybe it has a high learning curve (like vim).
I don't think so. I don't think vim was in any way lacking in productivity. I'm one of those weird people that actually really likes using plain vi though. I actually own the book [1] and I've read through it several times, trying to learn as much as I can about vi and ex commands. There's so much power there that a lot of vim plugins turn out to be unnecessary.
Others have tried kakoune and really loved it. I don't understand it. I really tried to figure it out, I just don't grok it.
Over the years I've used a lot of editors on unix shell; ed, jed, joe, pico, nano, emacs, vi(m) and I think vim is the best editor on shell for its performance, speed, and mobility. It's a rational choice for SRE/DevOps type engineers. I still sometimes use nano for very quick edits especially when having no physical Esc button frustrates me. However if mobility is not a concern, in other words if I'm editing files on my own environment (say my mac), I'm running Emacs.
I have seen nano to be the default for most debian and fedora derived distributions from early 2000s. Not sure if things changed in late teens. Or maybe I am misremembering things.
on more consumer grade distros I've had to `export EDITOR=vi` before to get vi to come up for things like `crontab -e` and for `git` messages. But it is the default on most systems I've come across personally.
I knew vim was old, but had no idea the lineage traced back 50 years. Vim has always felt like an exoskeleton suit compared to the spaceship dashboard of full-fledged IDEs. You can also add plugins to gain most of the functionality of an IDE.
It does have a blood price, some days I spend just as much time hacking on my vimrc/plugins as the actual code I opened vim for.
Back in ye olden tymes, you could count on some variant of it being everywhere. It’s lightweight, ubiquitous, and powerful. It’s way more powerful than default Windows tools.
There’s a steep curve, but if you can handle it and learn a couple of things (%s//g) being one of them, you’ll get people hooked. Then the olds shame the young staff to use it.
The muscle memory aspect is significant too. I’m a suit now, but can still work magic with Vi years later. The faculty at my college pushed emacs hard, but customizations are missing on foreign machines, and the key combos were too awkward on normal keyboards (for me) and the skills wore off.
I used Vi, and then Vim, for a good 15y before I switched to Emacs. I made the switch because I had heard that Emacs let you manipulate your buffers with lisp as one would any other data in a programming language. I find I only really do that when using Org Mode or REST mode, but I'm still glad that I made the switch. The editor is ... mine. Mine in a way that a professional's tool should be an extension of themself.
I've been thinking of trying evil, but I don't really miss the modal editing as much as I thought I would, and it's been another five to ten years.
One of the things I like most about vim is that you can use it on just about any remote machine, and even if you don't have your own vimrc the default editor is still really powerful.
Why is vim so addictive, and somehow it's difficult to explain to non vim fanatics? I think it's a reification of the process of walking through a text file and doing stuff to it. A concrete way to talk about processes onto text files. Some feel it is strictly superior to GUIs because you can get ahold of it. you can write it down, put it in a postcard, and you have a handle to it. You type it again and it works. there's no syntax or fuzziness or stuff that can go wrong (TM).
Next question: Can you ahold an algorithm in your head? in the same concrete way you hold 'yypVr-'?
I'm lately quite interested in Array Languages and I'm reading some snippets of Apl/J/K. And the feeling is the same. Everything else looks so wasteful and error prone like the point-and-click looks to vimmers.
Example:
Shuffling a vector – breaking ⍵ down into ⍺ pieces from which another vector is built by merging. E.g. if is 'abcdefghij' and is 3, the pieces are 'abcd', 'efg', and 'hij', and the result is 'aehbficgjd':
⍵[⍋⍋(⍴⍵)⍴⍳⍺]
The ergonomics are pretty different from what we're used to, but there's definitely an emergent property there. It's not just "it's shorter to type".
In the early days, there was no such thing as an editor. Punch cards were used for every separate line of code. And along came editors. I had no familiarity with mainframe editors, but DEC systems had EDT/TPU (and another macro scripting thing I forget the name of). Enter 1980s with UNIX. This gave us ed/ex/vi/emacs. I entered the workforce in 1985, and had to edit files on a 1MB memory 68010 system. Emacs was such a memory hog that it would not run on said UNIX system. Fast-forward 15ish years: I have watched seasoned developers spend 2x-3x the time to perform simple editing actions in emacs than it takes to do in vi. Personally, I now have muscle memory for vi/vim, but if I need to edit a binary file, emacs or a hexeditor is the only way to go. IDEs add another level of context & capabilities to editors, as they typically understand the syntax of the language in question and often offer hints.
I know how I first encountered vi... it was probably 1994 or 1995... (Wiki looks like maybe 1994 was first intel release, so that tracks) - and I had only used Linux up to that point and had never really used an editor other than pico (now nano, which was the editor for the pine email client!).
I thought playing with Solaris would be "cool" so I installed it and couldn't get it on my network because I needed to edit the /etc/resolv.conf to add host resolution, but there was no pico editor!
I ended up digging into manual pages to figure out how to use vim, and over the course of getting the system set up I got pretty comfortable with a lot of the patterns vim let me make faster, they are mostly things I might run in a shell like grep or awk, but I can do it without shelling out, so that was a bonus.
edited: now that I think of it, I bet I was not using vim, just vi - so the relevance to this article might not be quite on.
real answer : because redhat and debian had replaced elvis with vim as the default vi early on. I don't remember the exact drama, but maybe something to do with the license.
elvis was great! The simple monocrhome color schemes were beautiful, and it had a snappiness (even on a 486 back then) that I'm still missing nowadays.
I've been a vim user for almost two decades, but recently my usage has increased dramatically due to the proliferation of high quality LSP servers that plug in through CoC.nvim. It really has removed all the maintenance hassle of keeping your language environments up to date.
Vim (bindings/modality - ESC mapped to CAPS) are good for my hands. I don’t get tired. Before vim my hands would get tired after some time. Now it feels like I can keep going forever.
Now I use vim for everything and it’s bindings in my browser, email client, todo list app, etc.
I was an emacs user until I had a summer internship where I had to constantly rebuild SunOS and Solaris boxes. No emacs in the default install and no working networking. But vi was there and it became my default everywhere.
Fast to start. I use Emacs for programming but if I have one single file, like a config file, that needs a quick edit, use vi(m) because otherwise I have to either:
1. Go to my open Emacs and navigate to the location of the file needing the quick edit
2. Open a second Emacs instance, and hope I don't lose the desktop settings for the "real" instance.
Especially if the file needs to be edited sudo.
If there is a way to open a file in the existing Emacs instance without navigating, I would be glad to use it except for sudo.
The way that "firefox some-local-file.html" will open up that file in the existing Firefox instance.
Even though I live in Emacs, I frequently use GP's workflow as well. For me, it's often the fact that I am already working in the terminal when I need to edit the config, so going to Emacs is a context switch. Moreover, I often fist do a cd /path/to/config; once there it's trivial to do vim foo or sudo vim foo.
I have an alias that can send that file to emacsclient -- but again, it takes me away from the terminal, and will not work with sudo.
Also, I've tried possibly every emacs package that helps with path completion, but they all seem to get in the way when I already know exactly what I want. Vanilla bash completion (and don't forget about fzf!!) are a better experience for me; YMMV.
Have been using vim for over 15 years and just a handful of commands have been enough for my needs.
Insert
Set paste
Save
Quit
Search
Undo
I know there are plenty more but for me is more than enough
No other text editor has so much in common with playing a musical instrument. Everything you do eventually becomes muscle memory; an expression of grammar rather than the execution of a procedure.
To me it's not about input being the bottleneck, but about Vim having a modular grammar, such that my brain can stay in "problem space" instead of "how do I edit the file space".
Perhaps a mix of choice supportive bias after going through the pain of learning it and stockholm syndrome?
Jokes aside, I don't really work with VIM but understand the concepts and have mastered basic usage of changing text files without too much effort. Never really coded in VIM aside from small scripts. But it is a dependable text editor that survived the ages. Most modern IDE will never reach this because they are far less dependable and far less wide spread. Installing VIM on your system never hurts.
Yeah I think ubiquity is a huge part of it. I think I'm at a similar level as you: I mostly use it for quick edits or when using ssh for example, but the fact that I know I will basically always have access to it makes it a good default choice.
vim has stolen years of productivity from me. i've listened to loudmouthed vim advocates, tweaked my editor settings, played with plugins. but the problems that i needed to solve - code navigation, autocomplete, debugging - were all easily solved by switching to visual studio. nowadays i use vs with the vsvim extension (years of vim trauma have burned the key bindings into my muscle memory) and am much more productive with that setup than with the janky vim config from my uni days.
Because modal editing is really, really fast? And if you edit a lot of code that’s really important?
I’ve used vim for ten years. I’ve always found the extensions to vim cludgy after a while. And I’ve happily hopped on to the sublime and vs code bandwagons because of easily extensible editors and nicer UIs.
But the first thing I do with this easily extensible editors is look for the vim plugin. Modal editing is the reason people love vim and if you don’t “get it” vim seems like a contraption only a sadist would love.
Every time I tried a new IDE I always looked for the setting or plugin that makes it work like VI. I eventually decided instead of making my IDE like VI I'd use vim plugins and make it my IDE.
I haven't found a way to test/debug in Vim that's as good as PyCharm. With PyCharm, after I write a test I hit ctrl+shift+r and it runs. I've been meaning to try pudb, seems like it's the most similar in terms of a visual debugger.
As a meta-comment, I'm always so surprised at how many people see an article title ending with a question mark and come straight to the comments to chime in with _their_ answer, without seemingly reading the article, which itself is a view on the answer to the question.
Do people perhaps mistake these types of titles as "Ask HN..." type threads?
At the interview for the position I'm in currently, the senior programmer I was interviewing with didn't pay much attention to my resume. He mentioned that he saw my .vimrc on Github though, and we chatted about that and other linux things. I think it was just a small connection in a big scheme of things, but it helped.
Remembering days when I was a sysadmin, vim or even old-school vi was the default editor on literally every POSIX/UNIX system, and I had to deal with quite a variety of them - BSD family, Solaris (still Sun), AIX - some of them still not connected to the internet! Having advanced vi skills appeared handy in my situation
Vim serves a very specific niche. Want to edit files on a remote server? This is the default option. Need to open a massive text file? Vim has got you where sublime, vscode fail.
I switched from emacs after college and haven’t looked back. Plus everyone constantly ridiculed me for using it.
> But what kept Vim in the loop is the compatibility with almost everything you can think about. Wherever you SSH today, you can start the Vim session, or at least Vi session.
Also the fact that it works over ssh. Emacs does too I think, but e.g. JQt and DrRacket do not!
I don't get vim. I use emacs primarily and I know to get around in vim but I've tried several times to see what the fuss is all about. Modal editing just doesn't work for me. It seems like a must to remap the escape key at the very least.
I'd classify vi (and vim) as originally being ubiquitous not necessarily popular. They have been a necessary part of my career since the start. I'd assume that is true of a lot of people here.
over two decades I used emacs, eclipse, geany, nano, even jetbrains whole bundle purchase plus a few other IDEs, I always return back to vim, recent years I have settle down on vim for good with a full IDE in terminal, I have code auto completion, syntax highlighting, snippets, linter, auto fixers, debugger for all the languages I care, it's just so beautiful and productive as well as powerful and lightweight, can't live without it.
Because people work with virtual servers a lot these days and vim is the easiest editor to throw on there and use without changing the defaults, is my answer.
I think a significant factor is that Vim is a better managed and maintained project. Emacs's difficulties in this regard are decades-long and songs are sung about them.
System administrators started using it because it's one of the best non-GUI editors (along with emacs), so it had this mystique around it. Those who knew VIM/emacs were surely hackers! And so programmers picked up on that and using VIM/emacs is a sign that you're cool.
in TRS-80 BASIC, you could go `EDIT 100` and bring up a line 100 in a line editor, vi sort of reminded me of that when I was learning it something like 25 years ago. It is still my main code editor.
Distressingly little comment on mode/modeless difference. There are reasons people want to be in a modeless editor, and there are reasons people want a distinction between insert mode and other modes. The primary drive for vi and emacs was the emergence of full screen editing? Sure. That was true, I lived across this window.
But.. it was possible to choose to get a 'page' worth of view of your teco or ed or SOS edit session, and return to a sense of being mid-page, if you wanted. It took some finicky commands but once you decided you needed a screen of context there was a way to do it, and not lose your point in a line.
(certainly, not lose the line you are "on")
For a DECwriter, this made very little sense to use frequently. It was best not to have to force it to print a lot of paper. For a slow ADM3/5 or VT100 it made some sense, because the repaint speed was a major pain.
Once you had sufficient responsiveness (2400? I would say that was about it. 4800-> was a no-brainer) then the repaint delay was low enough it was worth the investment.
There was another universe: Half-duplex. We just pretended it didn't exist, and that local mode entry didn't exist and designed systems not to even think about it. Odd, when you think that X10 was primarily about converting from server side to client side burden, which is local mode.
(server/client being reversed concepts in X10/X11 its confusing to talk about this, local being the key point)
I think vi took off, because a substantial proportion of the world did not want to think programmatically in LISP and wanted the reassurance of a moded editor, to do things. Emacs took off for people who wanted to hack the editor, more than the limited vi macro facility, and who wanted to be "in" the editor all the time. VI users wanted to distinguish being "in" the body of text/code and being in 'move around, and think about it' states of mind.
Had I turned left in 1979, I would have walked into a teco training room, and naturally been Emacs ever since. I walked right into a TOPS-10 SOS world, and emerged through PIP into ed and then ex/vi and then vim in the late 201x era. I personally preferred Keith Bostic nvi for a long time, and I still miss some of its innate simplicity. I was a late arrival in colourised editors. (this is not an analogy btw: it was literally random choice which room of two you went into in the first Year CS degree training for computing. We all used punched cards before this, and it was a DECwriter lab with very preciously guarded pre-ANSI terminals, too few to go around. Some of the DECwriters were converted to greek for APL, and we had a tectronix vector display which could be used as a text display device too, if you could stand the burn-in)
What often gets missed, is MIT, X and the emergence of EMACS key bindings as the go-to for line edit in the web. This and bash, had huge influence
So we now have a world of VIM users using classic VI bindings in editor, but using EMACS to do all line edit on the shell an d in the omnibox, all because of MIT and the X windows system and how that influenced graphical display norms when the first browsers emerged.
capability as well. In which other editor (other than vi/vim series) can you find and replace a string in a particular range of lines, and go to the 3rd occurrence of a letter in a line and so on!
And once I got used to it, I couldn't really imagine using computers any other way. I'd go so far as to say that the 'home row' concept of vim is the ergonomic ideal of keyboard based computing, and I now try to mimic that behavior everywhere -- the vimium extension in chrome, various vim plugins for vs code and sublime etc. If you're on the fence, I'd urge you to give in!