> 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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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!
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.
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'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.
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.
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!
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.
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 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.
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.
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.
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.
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 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.
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.)
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
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.
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.
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!
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!
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
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.
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
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)
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.
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.
> 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.
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 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.
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.
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.)
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 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.
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.
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 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.
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.
>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.
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.
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.
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.
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.
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).
(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.)
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.
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.
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.
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.
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.
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
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.
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.
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!
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.
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.
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 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.
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.
>>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.
> 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.
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.
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.
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 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.
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.
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?
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.
> 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.
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.
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?
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
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.
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.
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.
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.
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.
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.
Interesting point, and a good reminder of how anglocentric the computing world is in some ways. Do localized IDEs typically take this into consideration?
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.
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.
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.
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'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.
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.
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.
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.
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.
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.
506 comments
[ 5.5 ms ] story [ 309 ms ] threadI wonder what Vi(m) would be like if it were redesigned from scratch.
But I think Kakoune https://kakoune.org would fit the bill
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.
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.
[1] https://www.oreilly.com/library/view/learning-the-vi/9780596...
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.
> 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?
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.
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.
Here's a couple of the videos I watched:
1) https://www.youtube.com/watch?v=dr_iBj91eeI
2) I've only watched a couple of these for the topics I'm interested: https://www.youtube.com/watch?v=rCMh7srOqvw&list=PLhXZp00uXB...
3) for common VIM, I went with this: https://thoughtbot.com/upcase/onramp-to-vim
4) Recently, I found this guys short six-part series that gets you navigating around VIM fast, but he's an acquired taste: https://www.youtube.com/watch?v=H3o4l4GVLW0&list=PLm323Lc7iS...
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.
(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.
1: https://github.com/martanne/vis 2: https://en.wikipedia.org/wiki/Sam_(text_editor), http://sam.cat-v.org/
Ctrl+C esc esc Ctrl+c Ctrl+q
What is this! What is going on!?!
15 minutes of searching on my phone later, q...
So as a result vim has become the reference implementation for the POSIX vi featureset.
„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.
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!
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.
These are vital features from my perspective, but completely orthogonal to whether an editor has a post 1980s interface.
And it's also nice to be able to handle large files.
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.
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.
To be sure that the editor isn't in insert mode. Using another slot of short-term memory to keep an editor's mode seems wasteful.
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.
Nevertheless it is a limited resource.
> just press Esc to make sure
It's better to press Esc twice. Otherwise there's a risk of terminal emulator interpreting a command as an escape sequence.
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.
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.
Not just olden times. It is easily found on literally any Linux or Mac system.
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.
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.
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.)
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.
There's even a list[0] for that, Vi is the beast.
0: https://vim.reversed.top/
Is there are story here? This must annoy the whole office!
> 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.
https://m.youtube.com/watch?v=2XLZ4Z8LpEE
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.
Ed is the standard text editor!
[0]: https://www.gnu.org/fun/jokes/ed-msg.en.html
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!
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
For a well worn joke on the subject, "Ed is the standard!": https://www.gnu.org/fun/jokes/ed-msg.en.html
- (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..
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.
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
You could use emacs for that. Editing over ssh using TRAMP works perfectly in every case I've used it.
This post is what got me started on Vim: https://stackoverflow.com/questions/1218390/what-is-your-mos...
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
> 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.
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.
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)
vim scp://user@myserver[:port]//path/to/file.txt
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.)
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.
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.
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.)
[1]: https://github.com/akermu/emacs-libvterm
> I'm fine with Vim, but I'm glad I tried Emacs for a while because it does have some nice ideas.
I ended up with the same conclusion :).
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.
``` set -o vi ```
problem solved! no more emacs pollution!
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.
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.
(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.)
By far the most irritating thing about others' keyboards is they have not disabled it yet. Second most is that Ctrl isn't there instead.
I keep a caps lock on my programmable keyboard for this (Fn+K).
I also like SQL to be formatted with capital letters for keywords.
Probably don’t even need visual mode that’s just how I work.
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 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.
ctrl-[ (for right hand) or ctr-3 (left hand, thanks teddyh) => escape
ctrl-i => tab
ctrl-h => backspace
ctrl-m => return
ctrl-w => delete prev word
ctrl-u => clear line
ctrl-o => cmd mode for 1 cmd
...and many, many more, including all the completion options.
https://github.com/alols/xcape (for linux)
https://apple.stackexchange.com/questions/132564/how-can-i-r... (for macOS)
https://github.com/ililim/dual-key-remap (for windows)
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.
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.
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.
0: https://youtube.com/watch?v=XA2WjJbmmoM
1: https://vim.fandom.com/wiki/Using_marks
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.
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.
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.
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.
Its also a good sign that they might be into technology for its own sake, which also doesn't hurt.
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).
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.
I'd be VERY interested to hear why that's wrong and what you do differently.
[1] https://hhkeyboard.us/pro-classic/
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.
That gives a left handed option for escape without leaving the home row. I really like having mirrored shortcuts like that, thank you.
I switched back to vim+tmux (nvim) a few weeks ago from a number of years using vs-code with the vim keybindings.
I'm still trying to configure my plugins so that I don't feel like I'm repeating myself too often.
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.
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!
With "performant", I assume you mean "how well it works", not "how fast it works"?
FWIW a better adblocker is in progress: https://github.com/qutebrowser/qutebrowser/pull/5317
> 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
Yay... You can always customize the hints.selectors setting to add selectors for those (for websites you use a lot).
There are also some thoughts on how to add hints to all elements with a JS click handler, but I haven't had a chance to take a closer look yet: https://github.com/qutebrowser/qutebrowser/pull/4817
Exactly, sorry, not a native speaker.
> Yay... You can always customize the hints.selectors setting to add selectors for those
Didn't know about that, thanks
I have also written off a portion of the web as not being worth mytime, however.
https://github.com/andmarti1424/sc-im
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.
https://sanctum.geek.nz/arabesque/series/unix-as-ide/
Edit: Link
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.
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?
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).
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.
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.
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.
What IDE features do you think vim is missing that aren’t available via LSP plugins?
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.
I'll just point out that the things you've discussed are possible in Vim if you want them.
E.g. live-templates (snippets) https://github.com/neoclide/coc-snippets
and that if you don't want to spend the time configuring yourself projects like https://spacevim.org/ exist.
Now there probably are some IDE features that vim can't replicate with plugins but it's very rare to see someone actually provide an example of one.
Something like a profiler with flame graph might be an example. Things like refactoring, completion or fast command search probably aren't.
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 ...
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.
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.
Here is an example for typescript users.
https://thoughtbot.com/blog/modern-typescript-and-react-deve...
Again this does require you to configure things and that may not be what you want to spend your time doing but it's perfectly possible.
Also I'll add that I'm not arguing that vim is better than any other particular IDE or editor, just that IDE like features can easily be added.
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’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?
I don't think that you should.
I'm only addressing the point that vim can't be used to do IDE like tasks, which with LSP support it clearly can
...but right now you will have to configure it if that's something you want. If it's not then you're good to go with your favourite IDE already.
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.
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.
Then we mutually tried out linux and editors. He picked Emacs, so I went with vim. Haven't regretted it ever since.
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?
This helped me back in the day: http://yannesposito.com/Scratch/en/blog/Learn-Vim-Progressiv...
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.
https://github.com/TheNaoX/vimtutor/blob/master/vimtutor
It's a great start.
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.
Interesting. I generally use IDEs Pycharm or Eclipse, or VSCode depending on the language. Do you think I would gain a lot from learning VIM?
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.
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.
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.
*) US, not UK. UK QWERTY is trash.
I have learned hundreds of tools and IDEs over the years, and nearly every one is defunct and not used any more.
Every minute I've invested in learning vim has remained relevant and useful.
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.
Now I use vim for everything and it’s bindings in my browser, email client, todo list app, etc.
... vi was written for a world that doesn't exist anymore.
... programmability and the modelessness. Those are two ideas which never occurred to me.
I think this was the page that started me down that path: https://realpython.com/vim-and-python-a-match-made-in-heaven...