How Did Vim Become So Popular?
pragmaticpineapple.com
pragmaticpineapple.com
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.
type_a_constant ctrl-[ vawU
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.
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.
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.
setxkbmap -option caps:super
xcape -e 'Super_L=Escape'
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.
inoremap jk <esc> inoremap <esc> <nop>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.
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.
I've been engineering now since 2002 so approaching 20 years and sure, every office has one guy who's the "hardcore" Vim guy. Everyone else in the office uses Visual Studio or VSCode, Atom, Sublime, IntelliJ etc. But the "Vim guy" is the by far the loudest guy in the room when it comes to discussing his editor, tries to tell everyone else why their editor sucks, how superior Vim is, etc etc. Meanwhile all the users of VS and other editors quietly get along with their work and feel no reason to advocate for their editor like it was a religion.
At my current company it's the same. We have maybe 300 engineers. 99% of them use VS or VSCode, there's probably one or two guys using Vim and still telling everyone else they're dumb for using VS... In 50 years when things have changed completely, there will probably still be some guys using Vim telling everyone else they're wrong for using VR Coding with voice recognition (or whatever is happening in the world of coding then).
Today if I'm conducting an interview and the someone tries to convince me he/she is a good programmer and just use vi/vim, I need to rethink my decision because it can compromise the whole project. I'm not saying they are not good, but having the capability of fast debugging and solving problems fast is crucial sometimes and is part of the whole package.
I was that kind of person someday and I understand the feeling.
But for devops, vim or emacs are the all-in-hands tool and everyday editor, just because they are available in everywhere and work very well on terminal mode.
Do you know who would likely "compromise a project"? The junior dev that is unable to stray outside their IDE when getting things done.
Line debugging becomes less and less valuable as you become more mature in you dev career. Sometimes you have a race condition bug, some times the target architecture just doesn't provide it (devkitpro/devkitarm or embedded) and sometimes bugs that are evident in production just cannot be replicated in your debugging environment.
In my experience it is more valuable to improve skills of building mental models of the system at hand, get effective with console logging for key info and troubleshoot issues that way.
It happens, yeah. What mostly happens is that 99% of software development has debuggers available and that they are infinitely better and more useful when resolving issues. Printing, then realizing you don't have enough info, chaning your code, recompiling, printing, etc, is just not good software development practices.
Live with your constraints when you have no other choice. Use the tools that have been a standard in the industry when they are available to you.
1. Read the logs.
2. Read the code that produced the logs.
A few of my colleagues are vim users, and fortunately for the others we are not as vocal as you describe. I already accepted of being the weirdo that uses vim, because my programming skills make up for it ;).
I do have a shortcut to disable it, when we do some pair programming.
How is that these days? I used it a couple of years ago but it had issues at the time, namely some performance problems and getting stuck in a particular mode.
I ended up abandoning vim bindings because the JetBrains plugin was also buggy, and I straight up had no feasible way to get those bindings in Xcode, but I hold out hope for a glorious LSP-based future where I can just use vim and get all the benefits of my other editors.
I tried using VSCode with the Vim plugin for a while but the latency and inconsistencies eventually got me back to proper (neo)vim. UIs are almost always more complex and subtle than people intuit, have a large surface area, and make lag and inconsistencies most noticeable.
I love it, and using anything else feels weird. I remember having some problems with it before as well, but I haven't bothered looking at the settings or anything for months. I had to go back just now to see if I had any weird configs set up, (I don't)
~25% of web devs in the SO 2019 survey said they used VIM as their editor. Amongst dev-ops that number is higher, around 40%.
https://insights.stackoverflow.com/survey/2019#technology-_-...
So your anecdotal example of "99% of people using VS or VSCode" doesn't ring true for the industry as a whole.
I do not use Vim as a daily driver at all, but I have to use it sometimes because I have no other choice (remoted in to a box). So if I had to say which editors I used, Vim would be there... sometimes.
For my part, when I answered the survey, I checked vscode, intellij, vim, jupyter, emacs, and rstudio. Most of those are there because they're my preferred editor for some task or other, but vim is only there because it's the only editor I can expect to have available on every server I ssh into. So, while I did say that I use vim in the survey, I would encourage you not to count me as a vim user for the purposes of any popularity debates.
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
If company policy is that "we use X", then probably you're not going to have many people stray from that. The bigger the organization, the more likely you are to have strict guidelines in place like that.
I would guess people on Windows are also less likely to reach for Vim than any of the many other alternatives. If you're using Linux, you probably have a different view on the world to begin with, and are more likely to go with vim over whatever is the "new hot editor". I've heard Mac users like to reach for XCode, but I don't actually know many developers outside of work, and none of them use Macs, so I don't know.
It's not like Vim is perfect, and even taken the sharp learning curve apart, there are many things that are not ideal. But so are other tools. I tried some IDE here and there, but never found an improvement in my productivity – which would be certainly easier to improve by not going to sites like Hackernews. :D
I do find some things in some IDE horrifying, like having the amount of RAM consumed by the application displayed in the default interface, and seeing it growing while you don't ask anything to the application. I mean, even dropping the fact that it does require so much resource to do nothing, what a strange idea to clutter the interface with this data if the goal is to let users focus on there issues.
But that's no reason to be zealot of any other editor, including Vim. I'm rather confident that going with a matrix with measurable metrics, Vim wouldn't have rated 100% everywhere nor any other tool would.
To me the greatest feature of vim is that it's available virtually everywhere, so you can take it and the skill you gained on it everywhere. It doesn't make it something should use all the time, but it makes the point on how it might worth the effort to start learning it. That also a positive retro-active loop, that explain "why Vim is so popular", I guess.
I’ve never used vim, mind sharing what it’s weaknesses are?
I use ctags and macros to move around code but its not always perfect.
But then again there are many things I dislike in modern IDEs, I don't think there is a ideal solution, just like there is no one language to solve all problems.
That's interesting because code browsing and inspection are by far the most important reason why I use a modern IDE. I tolerate all their weaknesses (slow, high memory consumption, errors after updates, etc.) because of this. I am surprised that somebody would say "I am using editor XYZ despite its weaknesses in code browsing and inspection".
I don't think that's just a coincidence.
So it depends on what you value more.
1. Code Browsing is an initial, one time cost when learning the code base. After you learn the code base, I've needed this ability much less.
2. Adding plugins like NERDTree and fzf/ripgrep have helped make code browsing much easier in Vim. The downside to this is that if you're new to Vim, you need to learn how to use these plugins on top of learning how to Vim. So it's just more to learn. But you can also think of this as another one time cost in general.
Recently a lot of quality plugins have been made leveraging Microsoft's languageserver capabilities to provide many of these features for NeoVim/Vim:
https://github.com/neoclide/coc.nvim
In many cases it's better than an IDE because the code-inspection, linting, etc etc, can be done using the same exact tools as what your CI is using behind the scenes.
Also, having a languageserver for Rust/C++/JavaScript/TypeScript/Bash etc etc, all configured through coc avoids a lot of the jumping between IDEs/editors/tools to get reasonable completion and code navigation between each.
With that in mind, I've used VIM for probably under 10 hours total, mostly for editing config files within headless Linux installs. For example, setting a static IP in Raspbian so I could SSH in once I put the pi somewhere it was online but not physically accessible. VIM is really neat for stuff like that. I'd love to have more reason to learn the interface but barring a weekly use I'd quickly lose familiarity and am focusing on javascript functionality as one of our apps can run js scripts.
So for quickly editing files with a known structure like setting an IP address in Linux or updating code you understand, I can totally see how VIM is amazing. Lightwight, almost always there already so standardized, quick to navigate when familiar, and more. As a fairly novice level coder I'll stick to an IDE with scroll ability and a mouse/etc for coding, even for a slight update to something I wrote the previous day. I'm just not confident in getting it right the first time and know how to test or trial/error a command in an IDE much easier than CLI. If I was trained and focused on coding I bet I'd be way better at that stuff too.
Check out gvim - it's a graphical version of vim that gives you scrolling and mouse support.
It's not quite as graphical as a regular IDE but basic stuff like mouse and scrolling is fully supported. You can even use the mouse to e.g. resize tiled windows within the editor.
(I certainly don't use Vim for most of my coding. It's not good enough. But I do use Vi keybindings in VSCode, Visual Studio and PhpStorm depending on what language I'm using. I'm not particular enamored of VSCode either, btw, for the same reason that Vim isn't good enough - sure, it can do what you want. But you can't guess how to do it. You need to read the documentation. VSCode one ups Vim in just one way - it has a gui for searching and installing plugins. Visual Studio and PhpStorm allow you to browse the menus to find the facility you want. It may take for ever, but when you have some downtime, you can browse and use your learnings next time.)
But hjkl I need even in my webbrowser. (In Thunderbird I've send many mails to junk by accident.)
The fact that most popular editors and IDEs (every one you mention) have VI/VIM plugins suggests otherwise.
It's (usually) not the editor itself that people find appealing. It's the key bindings. It's the fact that you can navigate around a file without reaching for the mouse.
It becomes a hot topic of discussion without my wanting or really worrying about what other people are using.
I think the comparison to Veganism is a good one--- people think it's a flex, when in reality I just like it and it helps me get my work done.
Well of course not, because their editors SUCK!
> 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!
I’ve been using vscode for years and the YouTube videos that demo vim features are shallow (like how to enter a blank line - really?). I can do the same thing I have seen in vim videos without memorizing a bunch of strange key bindings all while being able to edit code instantly without changing modes.
I would love to see a fair comparison between someone using vim at 100% and someone using vscode at 100%.
Of course some vscode shortcuts might not be fair (like F12 to jump to definition, F2 to rename every usage, etc.)
But even in raw editing:
With vscode, I can do multi-line editing, I can navigate quickly, jump to specific words, etc all very fast.
If there is no video like this, would anyone be interested in a race?
"q10yy /jnk "w5yy 10G "qp "wp "qp
now, go to the start of the document and indent the next 20 lines by 10 spaces:
0G .,+20s:^: :
ok great, now find JUNK and replace 'a1' with 'A1' in the 15 lines that follow:
/JUNK .,+15s/a1/A1/g
probably not as efficient for multi-file refactoring, but for raw 'drag race' style text munging, everything is there, loaded in muscle memory, and under the home row of your keyboard so you don't have to lift your hands at all.
The real scenario is usually to replace, for example, in a function block. How do you do that? Counting function lines seems like a non-starter.
I believe this is an area where treesitter can help, so I'm looking forward to Neovim's integration.
Of course Vim can replace a function block easily and has been able to do so for decades.
Just thinking out loud how to do that in vscode for comparison:
- I don’t think repeating actions a specific number of times makes sense in most use cases. Counting 10 lines would take longer than doing shift up/down n times (which would be exact with feedback) to select the desired lines.
- Multiple Copy Paste buffers sounds interesting, I might look up a vscode extension for that. (Had a copy paste queue in Visual Studio but it would break sometimes and would lose something important).
- go to start of function jnk, there are many ways to do that in vscode. Ctrl+f jnk enter would be one.
- Goto start of document is Ctrl+Home
- Indent 20 lines by 10 spaces, could do Alt+PageDown, then up/down to get to the right place (without counting or caring that it is exactly 20 lines), then with multi-line insertions could space,tab, etc.
That operation would probably justify mouse usage though, in which you simply hold alt, drag ~20 columns/~10 cells and hit space - which itself would be faster than counting 20 lines.
- find junk: ctrl+f junk enter
- select 15 lines (shift+page down,up/down to adjust) I can preview I have selected the correct area, other possibilities to select current function, etc.
- Ctrl+h to replace, a1 tab A1 Alt+L Enter
- of course in most cases, I am renaming a symbol, so “F2 A 1 Enter“ would do
I think the reality is that counts are not known before hand, so being able to increment/decrement with visual feedback is perhaps faster than a miscount, but I’d have to see it to know.
Anyway, thanks for the detailed examples! I can certainly see how it would be powerful if committed to muscle memory, but even with vscode there are many shortcuts I don’t use because of formed habits.
There is never any "counting lines". If I need line's number, I can do a quick addition/substraction in my head or j/k $offset to see the other line's absolute number.
I can do line-based operations a lot faster than shift-tapping or click-dragging, with exact precision because my editor has been customized to provide the data I need. Eventually you get pretty good at estimating line numbers and character columns too.
Vim get round that by providing the option of relative line numbers to the current line.
That’s accessed via
:set relativenumberfor line counting - indeed a good point and clearly required for the examples -
After time, eyballing this becomes a skill. For things that fit on a screen (~50 lines or so, give or take) I'm usually correct 1st time or within a few lines. I can check quickly by moving the cursor (20j to go down 20, 20k to go back, repeat if necessary to get the line count)
also as others have pointed out, I might not be doing the best/optimal thing for some of these, just some examples of how I do things that popped in my head :)
For example, let’s say I have a json object with variety of field names, one per line and I want to remove the quotes.
With vscode, I can alt select all lines, Home Ctrl+right del cntl+right del.
The trick is the field names are different length, does vim have multi-edit with the ability to navigate relative to each insertion point?
Edit: Here is a good video example (https://youtu.be/iomWEDMBlcE)
Can vim do something like that?
I personally would rather use :s (search-replace) for that. Regexp is your friend.
If I wanted to cherry pick examples of what vim does better, I could start all of them with, "first ssh into a random server."
What makes vim great is that it has a tremendous number of features and is available nearly everywhere. Can VS Code do that?
If you’re on a new machine, you can grab your dotfile repo from wherever you keep it—like GitHub for example—and you’ve got your complete config, since there just text files. Takes 5 minutes.
But even plain vanilla Vim is more than enough for many tasks on a new Unix/Linux box.
Evil is also the best and most complete vim experience outside of vim.
For example you could use the visual block mode (ctrl-v) and highlight to the end of the line using $ and then use A to edit the end of every line at the same time. That works with lines of different length.
Or you could use a regex inside of a block selection.
Or there's a multi-cursor plugin available for the same approach as you're currently using in VSCode:
https://github.com/terryma/vim-multiple-cursors
Vim Golf is an excellent resource for seeing how to efficiently edit things in Vim: https://www.vimgolf.com/
> Here is a good video example (https://youtu.be/iomWEDMBlcE)
Again, you can do everything here without using multicursors, just record a macro for one line and repeat with a count and you're set.
Now if you absolutely want the multicursor feature, there are more than one plugin[1][2] for that, but I never felt the urge to use multiple cursors in Vim.
0: https://youtu.be/YR7rRC-vwj4
Nit pick: "q selects register q. A buffer is a different thing.
you totally can! I could talk for a while about customization and ctags to address some other points you made but at the end of the day its a text editor, vim and vscode are both text editors. it sounds like you really like using vscode so you should stick with it, I really love vim and it works really well for me, and my boss loves using a near vanilla sublimetext 2 install. programming will never be about typing and editing speed but being comfortable with your development environment and hopefully even enjoying it is very important.
It even supports using a mouse over ssh.
I don’t know SyncTex so can’t comment on that.
Now you're the creator of autojump, I just want to say your software is definitely a time saver, especially with this https://github.com/fdw/ranger-autojump, keep up with the great work.
Thanks for the kind words on autojump :) I'm no longer involved with the project, but I feel the general idea is still relevant.
What I did take from those efforts, though, was Vim's text navigation key bindings. They are a joy to use and most text editors have some sort of emulator for them. The beauty is in the chording, almost all of which maps to easily remembered mnemonics. Delete everything between quotes? Use di". Change curly brackets to square? Change surround, or cs{[. Once you've gotten used to switching between move and edit modes, you can layer these in bit by bit. At a certain point it becomes second nature and you do feel like you can edit code at the speed of thought. It's a powerful feeling.
Here's a tiny sample of some stuff I use constantly:
Move cursor forward word at a time: w ignoring punctuation: W reverse: b B
Move cursor to next occurrence of character Z: fZ reverse: FZ
Delete forward to next occurrence of character Z: dfZ reverse: dFZ
Change forward to next occurrence of character Z: cfZ reverse: cFZ (like delete but leaves in insert mode afterwards)
Repeat latest edit from current cursor position: .
A lot of the vi commands are composable, as illustrated to some extent above.
To search for say the next line starting with void: /^void
To delete from the current line up to the next line starting with void: d/^void
Note the similarity to dfZ/fZ from above, it's not 100% consistent but most times you can take a chance composing things as you'd expect and things work correctly.
There are far more sophisticated things too of course, but I'm not writing a vim tutorial in an HN comment.
You can do things like rename a function while rearranging its arguments either file-wide, or on a number of lines, or on an interactively selected visual region, or a section selected similar to d/^void... I presume other editors have such capabilities, but I'm most familiar with vim. In vim the actual renaming and rearranging is done using a regular expression containing backreferences:
s/old_func(\([^,]*\), \([^)]*\))/new_func(\2, \1)/
vscode has regex find replace, but I don’t use it very often. It does show every match highlighted in the current file while entering the find value, which is nice.
It does the same for multi files if needed and gives a nice preview of every change.
Word navigation I use a great deal (especially with multi-cursor editing). Ctrl+left/right jumps words, home, end to begin end of line.
Ctrl+f Z Enter would go to next Z value. (Which I don’t use, because I don’t think in partial words much, but rather jump to mouse if I need to navigate far)
That’s probably where I could gain in using that instead of going to the mouse every time.
Some other random things I use constantly (I am not the person you're replying to):
C — replace to the end of the line
xp — swap two characters (which I have to use more frequently than I'm willing to admit.)
ci( — replace everything in brackets (like the arguments of a function, this also works with " or ' for strings, { for blocks of code, and so on). The cursor doesn't have to be inside the brackets, it'll jump to the nearest match.
:earlier 10m — time traveling, which comes in handy between commits or with config files, especially if you configure vim to write persistent change history. What did this file look like a month ago? Oh yeah, :earlier 30d
. — repeat the previous command (this is much bigger than it sounds, as it allows you to repeat the same complex manipulation on different data in situations where you can't use multi-cursor, but which don't warrant building a whole macro.)
A ton of custom filetype- and mode-dependent <leader>-based bindings (which is the spacebar in my case). space-space to jump to definition, space-f to reformat the file, that sort of stuff. This can probably be done in vscode.
If you're really interested, there are tons of vim videos on youtube made by real vim pros. I am very far from being one. The best for me are live coding sessions where vim usage is demonstrated by doing the real work, not on some toy examples.
Another trick to my bag, that's why I absolutely love these threads about Vim.
For most features, the advantage seems very small, as the use-case is so rare, or it's not the limiting factor anyways.
But this is very limited to my experience. I am pretty sure, if I already knew those things, I would value that investment the same way the vim users do in the vim threads. But for now, it seems to me, that the investment is not worth the payoff and I am better off learning something else.
Then theres stuff like [c]hange un[t]ill [x], to change everything up to a certain character.
or [y]ank [i]nside ["], to 'yank' (copy) the text inside of a string and be able to paste it immediately anywhere I want to. It's verbs and sentences that you're writing in VIM modes.
Do modern editors have these kinds of keyboard shortcuts?
In general I think vim users are extremely bad at explaining why vim modes are so good, as I never use 5w. Am I really going to count how many words ahead I have to go? No, i'll just press [f]ind char to the word I have to go to.
The biggest thing about vim is that it doesn't make you more efficient or faster, it just eliminates the time you have to think about how to edit text once you internalize it, which I know doesn't sound likely because the keybindings are so strange. But know that I've learned it, i genuinely don't think about it, and every time I'm not in VIM and have to move my mouse and click on a character I feel like I lose my train of thought of where I was in the code
> But know that I've learned it, i genuinely don't think about it, and every time I'm not in VIM and have to move my mouse and click on a character I feel like I lose my train of thought of where I was in the code
I believe that, so please believe me when I tell you that I just have navigation with the mouse and other shortcuts internalised for many things. I'm not really actively thinking about it either.
Thanks for taking the time to share your thoughts!
Definitely! I just want to provide an actual reason for why VIM is great as people who are very into it are the worst at telling you why it's good.
It's usually, "well if you spend 3 months tinkering with configurations and plugins, you can basically have most of the features an IDE has out-of-the-box!" which misses the entire damn point of vim.
Also it's great because if you're ever ssh'ing into servers, you can be confident that you can be close to as productive editing files there as you are in your IDE, which I find very re-assuring. But as it is right now, I don't see a reason why anyone should switch to vim unless they enjoy the act of learning it and want to get some of the cool composability features, which are just fun to use and learn
Thank you for that, I value it! It seems I was unneccessarily defensive!
> if you're ever ssh'ing into servers, you can be confident that you can be close to as productive editing files there as you are in your IDE
That is a nice point.
The ones I can't do directly, I can do via Search/Replace functionality that is also standard in most modern editors.
Your example about refactoring a function by using text editing capabilities is actually pretty bad unless you mean Vim can actually parse your programming language and perform the refactoring over all your code-base (not just a single file), like any IDE will do.
This list you gave me just convinced me I don't need Vim.
WTF is a standard editor and standard shortcuts? Would that be ISO or ANSI?
Isn’t that just another way of saying I can’t do these things but don’t care? The Blub argument effectively.
No one's saying vim is superior. However, you need to have an open mind to understand the alternatives.
It's not like Vim is a paid product and by you not using it, Vim is going to die out soon or anything.
If you dont' like it, great? You are happy with the alternative, great. You seem like you just want to deliberately start an argument and then prove you are right, but why?
At this point, I feel like "I use Vim" is like "BTW I use Arch", said usually with an air of superiority as if choosing "the hard way" was somehow smart.
I can't speak for other vim users but I think it's pretty obvious to us how other users work without vim and we know you can be productive without it.
Personally I make a point of not telling people to learn vim but equally I think, for example, not having a shortcut to repeat a complex visual selection is a pain.
I never feel the need to enter a thread about IDEs and point out this missing feature (especially if it's a program I don't actually know well and that might not be the case).
However I often see people that don't know vim well make statements like "vim can't do x" without actually checking if that's true.
Then we look "superior" when we point out how to do it in vim.
It's hard to win because your argument sounds like an emotional one.
Modes are everywhere. My microwave has a defrost mode. Cars have reverse mode. Pill bottles have modes where the bottle has to be held differently to open it.
Modelessness isn't all it's cracked up to be.
I’ve used many editors on the Mac—BBEdit, SubEthaEdit, Chocolate, TextMate, TextWrangler and a few more obscure ones.
I switched to Vim and haven't looked back nearly 10 years ago because the "modeless" editors had limitations and issues I didn't like.
I used Emacs when I worked at MIT because that's what everyone used, but it never took for me when I had to use Unix.
What the author didn't mention is that when Ruby on Rails was the new hotness, so many of the leaders in that movement were Mac users, on TextMate. But when TextMate went into limbo, and then eventually died, that tribe needed a new editor and they essentially all moved to Vim.
Many of the early Rails videos were done on Vim; they were quite influential.
I wanted an editor I wouldn't outgrow in a few months and Vim fit the bill nicely.
And to this day, I feel like I'm pretty proficient with Vim but I also know I'm using like 10-15% of what Vim can do and it's nice to know all that capability is there for when I need it.
So if you undo something a few steps and try something different but decide you want to go back you can’t... but you can in vim with g+ and g-
If you add the Gundo plugin you can visualise this as a tree of diffs in a side window.
I’m sure that’s been added to IDEs as a plugin but in vim it’s standard.
It also persists undo state to disc if you want so if you return to a file on another day it’s still all there.
You select some text, either via keyboard or mouse. You realise you’ve missed a bit at the start of your selection.
In vim without having to start over you press o and it moves your cursor the other end of the selection and you can now extend it.
Deselect accidentally and want the selection again? Press gv.
I’m sure these little features are available in other editors but not always or not always by default.
As a 30-year Vi/Vim/NeoVim user, I can confidently say, "No, you can't."
I think the popularity of learning vim might be similar to what jiggawatts mentions as the 'perception of speed', especially for tools in the UNIX world, as well as being 'the hard way' like you mention. But I think there is value in learning how to use vim. I see the advantages of learning vim are programming language agnostic. Vim is focused around words and text, treating them as objects, and creating a mental map of keystrokes to modify those objects. I think it's somewhat analogous to typists that hunt-and-peck vs touch typists. Opens up a lot of productivity, but it's definitely not needed to be a writer.
I agree vim has many limitations. It has a not so great language for scripting, no out of the box setup for stuff like refactoring or renaming symbols in your codebase, GUI feels like a second class citizen (IMO, compared to the terminal version). In a lot of ways, it might not hold a candle to the likes of VSCode, Atom, Visual Studio, XCode, IntelliJ, Eclipse, etc.
The nice thing is that you could add a vim-like plugin to any of those IDEs/editors to match the spirit of vim, at least in terms of navigation. It's not like you need to stay in vim to reap the benefits of the mental model.
I think that's where a lot of the power and appeal of vim is. Vim is still drawing a new generation of programmers, artists, and hobbyists to learn this strange text editor, with its unique but powerful way of interacting with text.
How often do you really do things like this though? It seems like, sure you can do weird obscure things quicker in Vim, but only if you happen to remember how do to the weird obscure things, and it's only useful in weird obscure situations.
For 99% of tasks the built-in VSCode stuff does the job for me. Ctrl-D especially.
All the time. Some examples:
* ct, : "change up to comma", useful for replacing a function argument.
* ya" : "yank around '"'", copy the string literal the cursor is currently inside.
* ci( : "change inside '('", useful for changing the condition in an "if" statement.
* da{ : "delete (i.e. cut) '{'-delimited block", useful when changing the structure of if/else blocks.
I agree that these commands may sound obscure, and many Vim users use the program for a long time without using them (I certainly did). But when you start using them, you find that these composable editing commands correspond really well to many of the logical editing actions you perform.
As an example, say I need to add a comma to a bunch of lines. I will record the macro on that line appending a comma to the end, visually select all of the other lines to copy the macro on, and then jam my hotkey to apply the macro.
It's often much quicker than reaching for a regex for short segments of code.
V<count>j (3)
:'<,'>norm A, (8 - The angular brackets are automatically added by vim)
qq (2)
A,<ESC> (3)
q (1)
V<count>j (3)
<CTRL><Space> (2)https://www.youtube.com/watch?v=UDGG3hK4Bg8
Its a simplified version of a problem from work a while ago where we had to generate ui from lots of csv files. The last dev on it was taking weeks, but with vim I was able to come in and finish the boilerplate instantly. (We were commited to non-dynamic ui at that point, I think I made the right play especially with how we ended up using it).
Vim is, in my opinion, inferior to an ide or a good text editor, but if you have it as a plugin you get the best of both worlds and vim suddenly can do... basically anything you can think of. Like here's putting a breakpoint on every line in a file
The best part of vim in an ide is when you're pair programming and you do something fancy, and your friend says "Wait, go back, howd you do that??"
The way I would do that in vscode would be with a multi-edit, but it would get iffy at that many lines.
I‘ll record a video doing the same for comparison tomorrow.
This makes me wish there was a site for recording challenges like this where developers could race using their favorite tools.
Vim vs VScode would be an amazing way to learn tips from experts on both sides.
Both support plugins, so the possibilities are basically endless
Why would one be suitable for programming but not the other?
It just comes down to UI preference and whether you want to configure things yourself or not.
Why, oh WHY, do those #?@! nutheads use vi? http://www.viemu.com/a-why-vi-vim.html
1) It works well in environments where special characters will get mangled in various ways over different platforms. As long as ESC works, vim will do the work just fine. 2) The modes makes it very reliable to use when you have to make specific operations in exact places in text-files. This alone should make it the goto editor for sysadmins where you often have to make just a few character changes to a configuration file and be sure you do not change anything else.
A third reason when starting the work was also that Vim came by default on all out platforms so we knew it existed there and it was a nightmare trying to get approval for extra packages to be installed, but the first two reasons are what keeps me coming back to Vim whenever I need to do some text-file surgery.
Not sure though
MacVim is a bit clunky but I've gotten used to it. I tried to get YouCompleteMe to work with it but failed (the plugin interfaces are ... complicated). I can't get function name syntax highlighting to work to my satisfaction but still I've stuck with MacVim.
Maybe VimR (gui for neovim) or neovim + VSC will work. --- This works-ish. :s/this/that/ works but g/hello/p doesn't. But maybe it can. I'll investigate.
„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.
I mean sure, if you think IDEs are just slow, expensive text editors with fewer keyboard shortcuts, then you'll be disappointed, but features like "navigate to any symbol by prefix", "find all usages", and "Ctrl-click to navigate to definition" have no comparable analogue in traditional text-focused, non-IDE editors.
Not to mention visual debuggers, not to mention remote debugging! The VS IntelliTrace feature alone is worth the cost of the entire IDE.
Visual Studio Live Share lets two people concurrently use the entire IDE at the same time, remotely: https://visualstudio.microsoft.com/services/live-share/
There's just nothing like any of this in Vim or Emacs.
I mean sure, if you futz around with plugins, you might be able to reproduce some small subset of these features, but then you'd have wasted more of your time tinkering with the editor than actually getting work done.
What I've noticed with a lot of tools that trace their origins to the UNIX world is the perception of speed. Typing many keys rapidly to trigger shortcuts feels like you're doing things faster than moving a mouse cursor and then clicking something, because there are more actions per second. However, objective tests show that even highly skilled users aren't as fast at completing high-level tasks as mouse-users.
One study that shocked me compared wall-clock development times for a moderately complex puzzle problem. It was designed so that most people would have to debug the program at least once or twice. Participants could use any development environment and language. Among the fastest solutions were users programming in F# and C# using Visual Studio, at roughly 30 minutes for F# and 60 minutes for C#. People programming in languages like C, C++, and Java in typical Vim/Emacs environments took days or weeks to solve the same problem! Days!
I've observed this effect with "command line jockeys" too, where they're absolutely convinced that bash is some power tool that nothing can hold a candle to, and then they take hours to solve some problem that's three clicks away in the GUI.
But often there are other issues. IntelliJ and its siblings can be very resource intensive -- many complain about the Clion launching your laptop fans, and its RAM usage, for example. And the UI of many IDEs has so much chrome everywhere, the UI often gets in the way for many. You can hide it and deal with it in some IDEs, but not all. There are just a lot of things to consider when selecting an IDE. For example, Emacs avy-jump is a really neat plugin (similar things for vim as well), but you'd have to work hard to configure an IDE for these kinds of features as well, so it goes both ways.
And btw -- Vim macros are perhaps one of the best text editing features ever created, and you can't find that so easy to use and powerful in any IDE.
And just the joy of actually editing text - which we do all day - arguably greater with the vim way of doing things. It just puts you in a certain zone.
You can remote debug with GDB.
You can navigate to any symbol by prefix in Vim using regex.
You can "find all usages" via :Ag whatever-you-are-looking-for.
Just because you don't know how to do it doesn't mean it cannot be done.
> You can share Vim, Emacs, and your entire terminal with other engineers using Tmux or Screen.
I've needed to do that maybe once. People aren't usually very proficient with tmux/screen anyway, and clearly even less with your flavor of emacs or your vim setup. VSCode live share does that too, but whoever you share with will have their own plugins (+ you can share servers, terminals, etc)
> You can navigate to any symbol by prefix in Vim using regex
Any IDE has navigation by symbol built-in, and it's usually faster than typing regexes
> You can "find all usages" via :Ag whatever-you-are-looking-for
Not true, :Ag will find occurrences not usages, it's not aware of the AST (that I know of). IDEs have specific language-aware functionalities like "find implementations", "find declarations", "find usages"...
---
I'm aware these were just example of course and I'm sure there's things that vim does better, but the only real value I got from vim compared to other editors is the text-editing model that's noticeably faster when you're proficient at it
Note some of the Java solutions were over 40 hours, and many are over 8 (one working day)
The version I saw was informal, and included F# and C#. I remember that F# was roughly twice as fast as C#.
I don't know F# but a friend of mine does, and we both solved the sample problem. He did it in under half an hour. It took me just over an hour, but I could have done it in about 45 minutes easily except that I had (embarrassingly) misread the problem statement and wasted a bit of time.
I used Visual Studio's debugger twice, and that did actually help a lot to get the problem solved quickly.
People who are really good at Vim and C remind me of someone who is really good at using a shovel. As impressive it is to watch them work, they can't compete with a backhoe.
- focused mode essay writing
- editing ~/.config/thing.json
- formatting a shopping list
- cleaning up scanned text from a PDF into markdown
- opening an encrypted password file and adding your home insurance renewal details
- writing up notes on a job contract
...and that’s just two hours into my day. Vim is general purpose. IDE usage isn’t mutually exclusive. When I need API aware typeaheads then I also reach for REPL.it.
> I mean sure, if you think IDEs are just slow, expensive text editors with fewer keyboard shortcuts, then you'll be disappointed, but features like "navigate to any symbol by prefix", "find all usages"
helm-projectile-ag (which I have bound to C-p s s) does this: C-p s s \bSYMBOL shows a list of all usages and enables me to navigate to any of them.
> "Ctrl-click to navigate to definition"
M-. does this in Emacs.
> Not to mention visual debuggers, not to mention remote debugging!
With SLIME I have a full remote REPL and debugger. And it runs in a GUI too …
> Visual Studio Live Share lets two people concurrently use the entire IDE at the same time, remotely
You could do this with multi-tty within Emacs, or with Screen or tmux, or with xpra. It would not be as ergonomic, I grant.
> There's just nothing like any of this in Vim or Emacs … I mean sure, if you futz around with plugins, you might be able to reproduce some small subset of these features, but then you'd have wasted more of your time tinkering with the editor than actually getting work done.
So, Emacs doesn’t have features it clearly has, but even if it does then somehow that is also bad? What is this, a game of ‘heads I win, tails you lose’?
I mean, does Emacs have a whole UI for handling unit tests which can be made to run automatically anytime code is changed? Does Emacs have contextual right click menus for almost any eventuality? Does Emacs have a visual browser for your code? Can you debug graphics pipelines (with previews of the output images) in Emacs? Does Emacs have built in code performance analysis tools? etc etc etc etc I could go on for ages here.
You try and compare Live Share with multi-tty? What a joke! Have you seen LiveShare and what it actually offers? Easy to use, amazing UI, you can see where the other person is clicking etc etc. The reason people use these tools is because they accessible, easy to use, and "just work."
This is the opposite of Emacs. Yes you can add "some" extra functionality by Frankensteining Emacs but it is about 1% of Visual Studio out of the box and convincing any of your co-workers to go through the pain of trying to emulate VS in Emacs is a fantasy, and then having to keep it updated and not broken... hahaha.
..unless you happen to not be on Windows.
Another part is having to look for and install the third-party modules that make it actually work well (most of them are not included in Emacs because of Stallman and the FSF being ideologues).
As you say, keeping it updated and not broken is yet another part of the price.
That said, it's clear from your comment that you have not given Emacs a serious try, at least not recently.
There's no reason you have to, but you probably shouldn't complain about it so vociferously if you haven't.
Right-click menus that cover most use cases (jump to def, find references, format code, etc) are absolutely a thing with lsp-mode (which is not too hard to set up itself - install it via the built-in package installation UI, install language servers, and tell emacs to use lsp-mode in programming languages).
There are unit testing modes that kick off tests automatically on changes and let you know if everything passed (or give you a list of failures when some tests didn't). I've not used those myself so I can't speak to their quality, but they definitely exist.
Further, these tools work for a wide array of languages, with the exact same interface for all of them (and an incredibly discoverable, extensible one).
Some of us like that a lot, as well as the comfort of having all the code to reproduce our setup directly to hand. I probably have several more decades in this game, so losing my environment to an IDE company going broke or getting bought is not a pleasant thought.
Tradeoffs, for sure, but with valid arguments for both sides.
> Not to mention visual debuggers, not to mention remote debugging! The VS IntelliTrace feature alone is worth the cost of the entire IDE.
I use gdb and pudb, which are both CLI based, and have done so for years
> Visual Studio Live Share lets two people concurrently use the entire IDE at the same time, remotely: https://visualstudio.microsoft.com/services/live-share/
Tmux has let me do this for over 10 years
There are things I do not do in vim, but they are few. For example, I've developed a few Android applications as a side project and I used netbeans for it. For rust, go, c, python, I've always used vim.
Of course, but is it as easy as two clicks in VSCode? There's so much setup to get it exactly the way you want in the terminal, where as it "just werkz" out of the box for VSCode. I'm a VIM user, but i use vim plugins inside of IDEs for this reason
And another unpopular opinion: can we stop talking about hjkl cursor movement like the pinnacle of ergonomics? I get that people are used to that, but the only reason why that keys are chosen is because of that particular terminal used for making ed/vi. If moving the finger to reach movement left is so superior than anything else, default movement keys in games would be asdf, not wasd. hjkl is better than reaching for the arrow keys, but hardly ideal (I remapped arrows to caps lock + ijkl and to me it's way better)
Experience with Visual Studio plugin and VSCode, both worked very good.
> have no comparable analogue in traditional text-focused, non-IDE editors.
The same features have been there in TUI editors for many, many years. There is nothing visual about the backend that handles those queries.
Whether the interface is easier to use or not is a different matter, but the features have been there for decades.
> Not to mention visual debuggers
Well, yes, visual debuggers are better with a GUI, that is obvious.
> not to mention remote debugging!
Remote debugging is very common. What you are thinking of is visual ones.
> However, objective tests show that even highly skilled users aren't as fast at completing high-level tasks as mouse-users.
Citation needed.
Blender, for instance, is praised by artists for its hard modeling productivity thanks to all the shortcuts.
A few years ago when I worked in VS, I used all kinds of shortcuts. It does not matter that the tool has a GUI or not to make the keyboard useful. It is orthogonal.
> took days or weeks to solve the same problem! Days!
That is just nonsense. There is no way one takes days/weeks to "debug" something that takes 30 minutes in another general purpose language.
Either the task could be trivially solved using the .NET standard library and not the others (which makes it incomparable), or they picked up participants with no clue in the other languages.
The debugger or the GUI/TUI distinctions have nothing to do with that. A visual debugger is most useful when dealing with very big code bases that you did not write yourself. For a programming puzzle that fits in 100 lines, a visual debugger is irrelevant unless you are new to programming.
Then I think "maybe I'll try these IDE like plugins for Vim" and get so frustrated by the Vim plugin system that its back to vanilla Vim pretty quickly.
I use "IDE features" when writing Scala: vim-plug first, then vim-lsc + metals. The configuration of lsc is trivial (as in you can copy an example of less than 10 lines).
After using this for a while, I replicated the same experience in Python with python-language-server (I install it with pip --user), and it was matter of 5 minutes to setup. Before this I was using syntastic + ctags, and that required much more work.
May be is more work than getting the same functionality in VSCode, but it doesn't look a lot of work to me.
> Programmer standing next to the SAGE computer's control program
> Image courtesy the Computer History Museum and the MITRE Corporation
So as a result vim has become the reference implementation for the POSIX vi featureset.
Also, it is fast and reliable.
That said, I never bothered learning many commands, only the very basic ones, I spend much more time thinking than typing anyway and I always felt the productivity gains to be marginal.
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.
Is there are story here? This must annoy the whole office!
Where Vim shines for me is for creating and editing small files. I use vim for my journal, quick edits, and data wrangling when I need to get something into a nicer form (most often scraping links to pipe somewhere else). It's a great interface for editing temporary data.
Also, knowing Vim if you ever need to SSH into a remote machine is a must in my eyes. Nano feels sluggish once you get a feel for Vim, and, as the article mentions, you can fine Vim almost everywhere you go.
Ctrl+C esc esc Ctrl+c Ctrl+q
What is this! What is going on!?!
15 minutes of searching on my phone later, q...
Type :qa and press <Enter> to exit VimActually vim had a larger share of users back then because there were not many other editors for UNIX and Linux. There are probably more vim users now but even on Linux I see many more people using VS Code. The problem they have is editing files when they ssh into a server. I usually suggest nano. Not many of them notice and understand the two lines menu at the bottom of the screen.
... vi was written for a world that doesn't exist anymore.
... programmability and the modelessness. Those are two ideas which never occurred to me.
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.)
1. vi is everywhere, and...
2. vi with no plugins is still super powerful, which is helpful on random hosts / coworker's machines / basically anywhere, and...
3. since vi is still so powerful out of the box, i only need a few lightweight plugins to close the loop and make the most powerful editor i can imagine needing. 99% of my plugin usage is fzf and ale w/lsp, which are arguably two very powerful plugins, but the cognitive overhead is very low, and at least among peers my editor doesn't seem to be slowing me down at all
i would also pose the controversial opinion/hot take that using a less "powerful" (non-IDE) editor helps you write better code. humans can only fit so much into their working memory at a time. vim doesn't really let me do crazy refactors or jump through endless chains of class hierarchies (well, with lsp it can, but...). compared to my eclipse/intellij days (and codebases worked on by other people using those tools) i am forced to tame complexity by defining good module boundaries and abstraction barriers.
When you see what influential programmers use, its clear that a disproportionate number of them are on vim/emacs.
Even that can be handled by Vim ootb, just add
path+=**
You owe it to yourself to explore and embrace the power of your tools as a professional.
Vi(m) in particular requires a deliberate effort from the user to learn its features, because of how it stays out of the way by design. It's not trying to be discoverable at the expense of experienced users.
Decades ago I tutored someone taking a C++ course who claimed to know vi and insisted on using it for the sessions. They knew how to use vi enough to be a notepad replacement, it was brutal to watch how much time they wasted neglecting to use any of vi's features at their fingertips. If you're navigating with a mouse or arrow keys, and treating vi as no more capable than notepad, you're not really using vi.
When I was younger I cared more about it, but it’s all just yak shaving.
What there isn’t are obvious benefits to keeping your fingers in the home row, just vastly overhyped anecdotes.
By the way expert photographers will tell you that it’s not about the tools and that today’s phones are good enough.
That’s one of the things that are annoying, I’m the dumb one for putting a dissenting opinion, but no one is willing to explain why using the mouse is worse, and definitely not in a way that satisfies me
If I ever need to do refactoring I'll download CLion and get the engine running and fans spinning. But I do more debugging and reading code than refactoring it.
If I was to say what do I like about Vim is the modal interface, and really because to me if feels right, I cant say that it’s objectively better
I 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/
It's not uncommon in the Vim world to remap Esc to CapsLock
It does have a blood price, some days I spend just as much time hacking on my vimrc/plugins as the actual code I opened vim for.
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've been thinking of trying evil, but I don't really miss the modal editing as much as I thought I would, and it's been another five to ten years.
One of the things I like most about vim is that you can use it on just about any remote machine, and even if you don't have your own vimrc the default editor is still really powerful.
Next question: Can you ahold an algorithm in your head? in the same concrete way you hold 'yypVr-'?
I'm lately quite interested in Array Languages and I'm reading some snippets of Apl/J/K. And the feeling is the same. Everything else looks so wasteful and error prone like the point-and-click looks to vimmers.
Example: Shuffling a vector – breaking ⍵ down into ⍺ pieces from which another vector is built by merging. E.g. if is 'abcdefghij' and is 3, the pieces are 'abcd', 'efg', and 'hij', and the result is 'aehbficgjd':
⍵[⍋⍋(⍴⍵)⍴⍳⍺]
The ergonomics are pretty different from what we're used to, but there's definitely an emergent property there. It's not just "it's shorter to type".
PS: I'm an emacs user (evil)
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.
Now I use vim for everything and it’s bindings in my browser, email client, todo list app, etc.
After using Vim as my main editor, my RSI went away.
These days I've gone back to an IDE but I still use Vim for single file editing.
Fast to start. I use Emacs for programming but if I have one single file, like a config file, that needs a quick edit, use vi(m) because otherwise I have to either:
1. Go to my open Emacs and navigate to the location of the file needing the quick edit 2. Open a second Emacs instance, and hope I don't lose the desktop settings for the "real" instance.
Especially if the file needs to be edited sudo.
If there is a way to open a file in the existing Emacs instance without navigating, I would be glad to use it except for sudo.
The way that "firefox some-local-file.html" will open up that file in the existing Firefox instance.
In Emacs you just C-x C-f /path/to/config, for sudo C-x C-f /sudo::/path/to/config.
Starting location will be home, or the parent of the active file (if the active buffer is an editor).
Even though I live in Emacs, I frequently use GP's workflow as well. For me, it's often the fact that I am already working in the terminal when I need to edit the config, so going to Emacs is a context switch. Moreover, I often fist do a cd /path/to/config; once there it's trivial to do vim foo or sudo vim foo.
I have an alias that can send that file to emacsclient -- but again, it takes me away from the terminal, and will not work with sudo.
Also, I've tried possibly every emacs package that helps with path completion, but they all seem to get in the way when I already know exactly what I want. Vanilla bash completion (and don't forget about fzf!!) are a better experience for me; YMMV.
For the other it's usually something like
/usr/x/y/z/a/b/c/config.ini
Yeah, I want to type that path into Emacs when I can
vi config.ini
sudo vi config.ini
I enjoy learning complex tools. Maybe that's why. I am also a JS developer, I guess it all makes sense now.
It allows me to have a deeper level of focus.
Jokes aside, I don't really work with VIM but understand the concepts and have mastered basic usage of changing text files without too much effort. Never really coded in VIM aside from small scripts. But it is a dependable text editor that survived the ages. Most modern IDE will never reach this because they are far less dependable and far less wide spread. Installing VIM on your system never hurts.
I’ve used vim for ten years. I’ve always found the extensions to vim cludgy after a while. And I’ve happily hopped on to the sublime and vs code bandwagons because of easily extensible editors and nicer UIs.
But the first thing I do with this easily extensible editors is look for the vim plugin. Modal editing is the reason people love vim and if you don’t “get it” vim seems like a contraption only a sadist would love.
I think this was the page that started me down that path: https://realpython.com/vim-and-python-a-match-made-in-heaven...
Do people perhaps mistake these types of titles as "Ask HN..." type threads?
I switched from emacs after college and haven’t looked back. Plus everyone constantly ridiculed me for using it.
Also the fact that it works over ssh. Emacs does too I think, but e.g. JQt and DrRacket do not!
This is my favorite and most useful Vim command.
But.. it was possible to choose to get a 'page' worth of view of your teco or ed or SOS edit session, and return to a sense of being mid-page, if you wanted. It took some finicky commands but once you decided you needed a screen of context there was a way to do it, and not lose your point in a line. (certainly, not lose the line you are "on")
For a DECwriter, this made very little sense to use frequently. It was best not to have to force it to print a lot of paper. For a slow ADM3/5 or VT100 it made some sense, because the repaint speed was a major pain.
Once you had sufficient responsiveness (2400? I would say that was about it. 4800-> was a no-brainer) then the repaint delay was low enough it was worth the investment.
There was another universe: Half-duplex. We just pretended it didn't exist, and that local mode entry didn't exist and designed systems not to even think about it. Odd, when you think that X10 was primarily about converting from server side to client side burden, which is local mode.
(server/client being reversed concepts in X10/X11 its confusing to talk about this, local being the key point)
I think vi took off, because a substantial proportion of the world did not want to think programmatically in LISP and wanted the reassurance of a moded editor, to do things. Emacs took off for people who wanted to hack the editor, more than the limited vi macro facility, and who wanted to be "in" the editor all the time. VI users wanted to distinguish being "in" the body of text/code and being in 'move around, and think about it' states of mind.
Had I turned left in 1979, I would have walked into a teco training room, and naturally been Emacs ever since. I walked right into a TOPS-10 SOS world, and emerged through PIP into ed and then ex/vi and then vim in the late 201x era. I personally preferred Keith Bostic nvi for a long time, and I still miss some of its innate simplicity. I was a late arrival in colourised editors. (this is not an analogy btw: it was literally random choice which room of two you went into in the first Year CS degree training for computing. We all used punched cards before this, and it was a DECwriter lab with very preciously guarded pre-ANSI terminals, too few to go around. Some of the DECwriters were converted to greek for APL, and we had a tectronix vector display which could be used as a text display device too, if you could stand the burn-in)
What often gets missed, is MIT, X and the emergence of EMACS key bindings as the go-to for line edit in the web. This and bash, had huge influence
So we now have a world of VIM users using classic VI bindings in editor, but using EMACS to do all line edit on the shell an d in the omnibox, all because of MIT and the X windows system and how that influenced graphical display norms when the first browsers emerged.