For what it's worth: I really don't care to tell people what editor to use. But I do think that everyone should think about spending some time with vimtutor. Not because it will turn you into a 10x developer, or because vim has the best keybindings ever, or anything like that. I've never bought it. But I do believe that it is very likely to make your life easier, even if you don't actually use vim.
Let me explain: I've been an emacs person for decades now. I was never super committed to it, though. In practice, I'll use whatever editor has the best plugin for the language I'm working in. Which means that, for the longest time, I had to try and keep track of 4 or 5 different sets of editor keyboard commands. Which is too damn much for one brain, so I found that, over time, I stopped being as efficient in any editor as I was in emacs 25 years ago.
So why vim? Because every editor worth its salt has an option to use vim keybindings. So you don't have to learn 4, 5, 6 different sets of editor commands. You can learn one, and learn it well.
> Because every editor worth its salt has an option to use vim keybindings.
Including the Unix shell line editor, which typically supports both vi and emacs key bindings, and nothing else. Yet for some reason the default always seems to be emacs rather than vi, even on BSD (e.g. OpenBSD), and even though POSIX only mandates vi mode because "[t]he author of emacs requested that the POSIX emacs mode either be deleted or have a significant number of unspecified conditions."[1] Emacs line editing mode is more confusing for me as I use Joe (WordStar clone) which has emacs-like key combinations but with slightly different assignments. And because of this default I've never made a habit of using line editing commands; there's no way I can unlearn my Joe muscle memory, and over the years I've gotten into the habit of avoiding shell personalizations, to my detriment in this case.
> Because every editor worth its salt has an option to use vim keybindings.
I'm not sure about this. For instance, I'm typing this message in a text box in my browser and I don't have access to vim keybindings. There are many cases where this happens (other example: google docs).
I do use vim whenever I can, but I'd say the most useful keybindings that one can learn are the ones from the OS.
I actually learned "vim" on Qt Creator's Vim mode and although I do most of my development now in "real vim" I very much agree with your post. Nearly every editor support vim keybindings which drastically reduces the different shortcuts you have to remember. Even among JetBrains products I find it helps a lot with consistency.
And this means that you can go between systems, not just editors. Before I learned vim bindings, using Linux was so punishing because I was used to using command/ctrl/shift/arrow keys and whatnot to select words, navigate to the beginning and end of the line, etc. After I moved to vim bindings for all my editors, switching to Linux was so easy that it's now where I spend almost all of my time. However, if I do need to use a Mac, I no longer have to fight muscle memory (except for that infernal super key copy/paste).
Agreed yes, and you could use CUA keybindings and be comfortable everywhere, working cross-desktop, cross-terminal, cross-platform. Only a minor variant on the Mac with Cmd instead of Ctrl. Some good options:
- Geany
- Sublime Text
- VS Code
- Notepad++
- micro
- ne
On top of these I usually memorize Ctrl-A and Ctrl-E for the command-line, and "i… :wq" for vim, although haven't needed the latter in a decade.
If you're interested in vim, but hesitant about the lack of IDE bells and whistles, VSCode's vim bindings are so good - with full support for e.g. splits, macros, buffers, ... - that I've finally converted to using that over raw vim.
Most anything that VSCode can do, you can make vim do with plugins, but it is often incredibly time consuming and finnicky to get up and running, whereas with VSCode everything "just works".
All the productivity of being able to edit text in vim, alongside the conveniences of a real, modern IDE.
I'll add that all Jetbrains products (IntelliJ, PyCharm, WebStorm etc) have the IdeaVim plugin which is also great, and it also respects some vimrc configurations too.
I always loved vims movement and editing and hated it's file traversal / project management, so this is a perfect amalgamation
I've recently been using VSCode+vim, after about 10 years of using only vim, and another year or so on Spacemacs (emacs + vim mode).
VSCode is awesome, it provides a ton of benefits you don't get from emacs or vanilla vim. I'm really enjoying using it, and there's a chance that it will become my new "main" editor.
That said, the vim mode is not perfect. It only takes a few minutes of work before I run into a limitation of the vim mode, some binding or other that I use and that isn't replicated. More importantly, some things feel broken - there have been cases where undo didn't work properly for me, and cases where numerical arguments to commands messed things up.
That said, I've actually started taking the time to customize the vim mode in VSCode, and it's starting to pay off.
My experience with VSCodeVim is that it's so slow it lags behind my typing. So I went the time consuming and finicky route instead, and it actually works pretty well. I can't think of anything I would get from using VSCode.
Thing is my vim setup is different than vanilla vim, and probably the same for lots of other vim users. Thus, vanilla vim bindings in other editors do not do much for me.
Agreed 100%, for anybody who has to use a Linux CLI with any regularity.
You don't need to be a vi/vim wizard, but you should at least be able to use it a little bit. Vi is the one editor that's guaranteed to be available basically anywhere.
For working on a complex file (local to my workstation), I almost always prefer Geany or maybe VSCode (depending on the scope of the project). But I'm also semi-decent with vi, and it's saved me a lot of times on embedded systems where I need to log in via serial-console and edit some files.
It's also just faster/easier for editing the odd config-file here or there on a system that I'm logged into. Sure, I could launch a GUI and browse to it (for a local file), or maybe edit with a GUI over SSHFS or something. But if it's a small change? Vim is killer.
Maybe Emacs is better for CLI use, I'm not sure one way or the other. But it's definitely got a much smaller install-base than Vim. And proper-noun Vim has a _much_ smaller install-base than vi-compatible things generally (vim, busybox vi, etc).
Programmers like using vim because it feels like solving a puzzle or RTS micro'ing and/or they have already sunk a huge amount of time into it and aren't willing to walk away (which is fine, but it's not evidence that these tools are better.)
Starting fresh (i.e. no experience with an IDE or vi/emacs) there is zero productivity benefit to choosing vi or emacs over a real IDE in this day and age.
Disclaimer: I am a former vi (~5 years) and emacs (~20 years) fanatic.
Thinking back to my first years as a professional developer, I remember floundering around an IDE trying to find the things I wanted. I ultimately decided that it was worth my time to pick an editor, learn it deeply, and stick with it. That's ultimately where the productivity gain comes from. Lots of people like to talk about how productive vim or emacs or VS code or IDEs are, but I really think it's the fact of knowing your tool really well that leads to the productivity gains.
Vim is great and I love it and have used it for 12 years day in and day out. But I wouldn't say it's what makes me productive, just that I got good at it and know it well.
> Programmers like using vim because it feels like solving a puzzle or RTS micro'ing and/or they have already sunk a huge amount of time into it and aren't willing to walk away (which is fine, but it's not evidence that these tools are better.)
I am (was?) a heavy vim user - 10 years, a .vimrc with thousands of lines and many custom code and settings.
I can vouch that in my case, one of the reasons that I did this is because I enjoyed it. I played around with many editors before I settled on vim, and I enjoyed it immensely. vim was my main editor for many years because it was the best at editing and still is. But for sure I wouldn't have sunk so much time into it without also having fun doing it.
In the last few years, I've started experimenting with other editors/IDEs using vim mode, starting from spacemacs, and now using VSCode.
A bit myopic. Programmers have many different needs and as with almost anything - it depends. "zero productivity benefit" is blatenly false for many people. Now for you, in your current needs, sure. But why attempt to paint the entire developer world your favarite color?
> Starting fresh (i.e. no experience with an IDE or vi/emacs) there is zero productivity benefit to choosing vi or emacs over a real IDE in this day and age.
vi/emacs will definitely still be around in 20 years. Other editors may not be.
IMHO the reasons in 2020 are the same of the last few years and are not changing any time soon: you don't need to leave the terminal AND it is everywhere AND (once you get used to it) it is extremely powerful and blazing fast (most "normal" people think vim users are having some sort of meltdown when they see vim users do even pretty simple stuff).
TBH, although this might be an unpopular opinion among vim users, I don't think vim is worth for coding beyond simple scripting, a decent setup requires way too much work which defeats one of its key points. But for everything else in editing files, nothing compares.
Not quite everywhere. At my current job, I have gotten somewhat proficient with sed, which is the most advanced editor installed on our production systems.
Also, for some reason, many modern systems still only install vi by default. If you know vim, you know vi; but it is missing enough features to be annoying.
The thing I'm running into recently is that it gets very slow for large files. Unfortunately, where I work, the norm is to have files be thousands and thousands of lines long, which causes my setup which otherwise works fine to become very slow.
It's probably a plugin I'm using, but as you say, it now becomes my responsibility to figure out which one it is. Contrast this with vscode, which works fine out of the box, and already has most features built in.
You're right, the benefits of a great debugger are so overwhelming that putting up with crummy key bindings is worth it. There have been many times where I've been plowing away in some $IDE, then swap over to vim to do some text munging operation in the file like converting some tool output into coded constants, and then swapping back into $IDE to continue the build cycle. It's right there, and it's so good at what it does.
> (most "normal" people think vim users are having some sort of meltdown when they see vim users do even pretty simple stuff).
You know, people always say this, but I've never seen that actually happen. And I've been using vim for around 10 years, with lots of customizations. I consider myself fairly proficient (though by no means an expert).
The reason I learned Vim in 2019 is b/c I wanted a lightweight, powerful, ubiquitous tool. I was willing to overcome the learning curve, but it took time. The most helpful advice I got was from this article https://medium.com/actualize-network/how-to-learn-vim-a-four...:
Week 1: Complete vimtutor once a day, every day
Week 2: Use Vim with minimal config, no plugins
Week 3: Use Vim with minimal plugins
Week 4: Compose Vim commands with verbs and nouns
I'm a vim user turned JetBrains user. I still use IDEAVim inside of all of the JetBrains offerings. I go back and forth wanting to purely use vim but I can't warrant all of the config overhead. To me that's the biggest reason not to use pure vim instead of a vimulator.
The vim ecosystem reminds me of the node ecosystem. It's a choose your own adventure approach. Yes, there are wonderful and powerful tools, but it's always a shotgun of plugins to get a solution for each language you want to support. With JetBrains, I get 90% of the tooling I need for the language I'm using out of the box. The other 10% can be handled by plugins and some small configuration changes.
I'm posting this because I want to be convinced otherwise. Here are the JetBrains features that I can't live without:
- Contexts: https://www.jetbrains.com/help/idea/managing-tasks-and-context.html#work-with-context
- Re > I'm usually working with a 6 to 8 way split. Kind of like the tabs on my browser.
- VCS tooling
- Handles multiple git repos from a top level. I can commit across all repos or a single repo selectively
- File change view
- Merging view
- Per line commit selection
- Inbuilt database tooling
- Ad hoc queries and output directly next to the code you're prototyping
- Database introspection
- Symbol based refactoring
- Visual debugger
- Multiple module repo
- You can configure a language/ecosystem per each directory in your project to get the associated tooling for each directory
- Scratch files
- Local history
- This has saved my ass more than once. It's amazing how far back you can go outside of commit history with this.
I use Visual Studio 99% for my coding, and Visual Studio Code for 1%.
I would prefer to use VIM for editing code or any text because it's a 1000% better than Visual Studio. The problem is, there's 50 other things you do with Visual Studio that is not editing code, and for those things VIM is not that much better, or better at all.
It's not even good at dealing with more than one file. Yeah, I have nerd-tree and have tried explore. meh.
I'll think about it when ReSharper comes up with an add-in for VIM.
Yes, I know Visual Studio Code has VIM mode. . and Visual Studio used to (or maybe still does), but then you're outside the norm of that environment. Ever Visual Studio Code extension is tested with Visual Studio Code. But they're not all tested with Visual Studio Code in VIM mode. That's why I like to stick with defaults and the base-case.
What's needed is for VIM itself to have features beyond just editing text files. It's never going to compete with Visual Studio or Visual Studio code until VIM itself adds those features that make a viable IDE replacement. Today, it ain't.
Here's my suggestion: give neovim nightly a try. With built-in language server support, many new features are easy to add. You can install it like this:
wget https://github.com/neovim/neovim/releases/download/nightly/nvim-linux64.tar.gz -O- | tar zxvf - -C /usr/local --strip=1
And the relevant part of dotfile that adds LSP support and enables a few language servers:
For dealing with multiple files at once, I would recommend using buffers and ideally a fuzzy finder, such as fzf. I would almost advise removing nerdtree while you get used to using buffers, as it probably shouldn't be used for a lot of tasks that it's tempting to use it for.
I also use a buffer explorer plugin and LSP servers too (go to definitions, find references, etc.), but buffers and fzf alone can be very powerful.
I use vim because its got :sp/:vsp, can edit remote files over scp, :E, :earlier, and now :term, plus so many options in vimrc. I don't think I really even need tmux w/ it anymore.
Wow, I've been using vi for 30 years and I had never seen :sp/:vsp, :E, :earlier or :term (although you can do :sp with ^W s). I always feel like there's still a lot of "hidden" functionality in vim that I need to uncover one of these days.
:term really changed the game for me. being able to run commands and then work with the output in other modes is so convenient. pair with neovim-remote[0], and it's pretty magical.
i stopped using tmux because now all i need to do is open a terminal buffer in a new split to multiplex. i rarely used it for sessions, but use abduco[1] for that now when i find the need.
> Notice how quickly you can select characters along a column. Please let me know if there is a way to do this as quickly and painlessly in other editors.
Drag your mouse while pressing meta on VS Code. I certainly think Vim is powerful, and I've spent enough time in it to be able to edit a file solely via ex. But I think VS Code is making some awesome progress, too. I like using the two editors together
> Notice how quickly you can select characters along a column. Please let me know if there is a way to do this as quickly and painlessly in other editors.
Yeah, what? Seriously?
JetBrains: command-shift-8 to toggle column select mode.
And if you forget that, just control-click and you can select it in the popup menu.
The only explanation for boneheaded statements like these are that vi/emacs nuts haven't used a modern IDE in decades.
Almost 3 years of VS code usage, I can not remember which meta key.
Doesn't help that I use a Windows keyboard on Mac some days, and a Windows machine on others.
Also mice suck (but are orders of magnitude better than track pads), I always find selecting columns this way to be super finicky and I often have to do it twice to get it just right.
Vim is absolutely awesome. I've been a heavy user for a good 15 years now, and yes, I was a very weird kid. Ever more so now, since covid-19 hit us, and the wfh saga began. I've been developing solely on vim. The only downside is that by the time my working hours are done, I'm usually working with a 6 to 8 way split. Kind of like the tabs on my browser.
Was taught VIM by my mentor in the early 2000s, along with Gentoo Linux and friends. I've since gone from sysadmin to "devops" to CTO - and VIM skills still rank as some of the most useful. VSCode in VIM mode finally convinced me that maybe being a developer isn't such a bad fate.
I'd also recommend Neovim[0], a community-led fork of Vim. One of the focuses of Neovim is exposing an API that lets other apps embed a headless instance in their UIs. This lets you use your Neovim editor along with all its configuration and plugins inside other apps! I've never been satisfied with any of the available vim emulator plugins out there for VSCode, IntelliJ, etc. (there's always something missing!), so this feature has been really valuable to me if I need a better debugging experience but want to use nvim as much as possible.
Someone's already made plugins that embed a Neovim instance right inside VSCode[1] and Sublime Text[2]. There's no emulation here, just straight up neovim running behind those buffers. I've tried VSCode with that plugin (though personally I like to stick to just neovim when I can), and I can say that despite some minor bugs it's been a pretty smooth experience. Even stuff like `gt` to change editor tabs is supported.
How does the Vscode and Neovim thing work though? I've tried to implement something similar for Kakoune and Atom editor, but i noticed that Atom would always manage its own buffer, and Kakoune as well, so i'd have to basically duplicate the buffers - passing tons of data around constantly.
I don't agree. I work in cloud / ssh environments all the time. My main computer is a mac and I need to copy text to and from multiple machines and the host machine. I write C++ and other languages on all the remote machines. https://micro-editor.github.io is the only viable alternative for me as its more modern and supports all the features I would expect from this distributed environment.
While I've only given micro a cursory look, it doesn't seem to have any particularly unique features compared to Vim, and from all appearances it's far less powerful. (This isn't the knock it might seem to be; it's hard to match any editor that's been under fairly active development for 25+ years.) I'm also not sure what you meant by "this distributed environment"; if you're SSHing to cloud servers and running micro in a terminal there, that's "distributed" in exactly the same way people have been running Emacs and Vim for decades.
My main computer is also a Mac and I also need to copy text to and from multiple machines and the host machine, and while I don't write C++, I do write other languages on all the remote machines -- and BBEdit lets me do that a lot more easily, since it has menu commands for save/open over FTP/SFTP. But it's certainly not unique in that regard. (Personally I've found Vim's netrw implementation of this a bit clunky and never got Emacs's functionality for this working quite right, although "Never Got Emacs Working Quite Right" may be my epitaph).
I don't think that the editing experience is the biggest selling point in VIM (although it can be very good). I think it's the ease of creating and integrating custom tools for the specific problem that you are dealing with, sometimes even for one shot demands. It's orders of magnitude easier than creating a plug-in for a mainstream IDE.
I use vim bindings with everything and am a full convert to modal editing.
But...
Vim bindings also feel like they have accumulated 40 years of cruft and evolved into some severely localized maxima. I'd be really interested in other attempts to do modal editing. Are there other attempts out there?
(Disclaimer: I use vim and vim bindings a lot but I am not really a vim power user.)
People who are extremely comfortable with vim + tmux look like they're doing straight up wizardry (probably the closest to what people imagine programmers do in movies). I remember seeing one of these folks during my first engineering internship and I was sold. Now I can't imagine doing most things without vim + tmux + the_silver_searcher + fzf (vim plugins).
The biggest downside for me is I don't think autocomplete is on par with other IDEs (even with YouCompleteMe, which is great). To be fair, this would be a massive challenge, considering how generalized vim is vs. an IDE like Xcode — which is purpose-built for writing Swift/ObjC. I feel like half of the time in Xcode I'm just hitting tab, and the code writes itself. I want that same experience in vim.
in all honest, is important to learn basic vim because is avaliable everywhere and there's a nearly 100% chance that at least vi will be in a random remote server you ssh into and needs to edit a quick config file.
That said, after use it extensive in the past, unless your editing code in a potato, for more complex work, I don't see a reason to learn advanced commands. You will be more productive with a modern text editor.
- does side-by-side file viewing with reasonable text size and low enough clutter for a laptop screen
- offers a great deal of editing power with no need for any extra preparation
Starting to work -- particularly at irregular times -- is much more fluid with vim. I usually need to take a deep breath before opening an IDE. Vim is just there, at my fingertips, all the time, and few competitors offer that experience.
[+] [-] mumblemumble|5 years ago|reply
Let me explain: I've been an emacs person for decades now. I was never super committed to it, though. In practice, I'll use whatever editor has the best plugin for the language I'm working in. Which means that, for the longest time, I had to try and keep track of 4 or 5 different sets of editor keyboard commands. Which is too damn much for one brain, so I found that, over time, I stopped being as efficient in any editor as I was in emacs 25 years ago.
So why vim? Because every editor worth its salt has an option to use vim keybindings. So you don't have to learn 4, 5, 6 different sets of editor commands. You can learn one, and learn it well.
[+] [-] wahern|5 years ago|reply
Including the Unix shell line editor, which typically supports both vi and emacs key bindings, and nothing else. Yet for some reason the default always seems to be emacs rather than vi, even on BSD (e.g. OpenBSD), and even though POSIX only mandates vi mode because "[t]he author of emacs requested that the POSIX emacs mode either be deleted or have a significant number of unspecified conditions."[1] Emacs line editing mode is more confusing for me as I use Joe (WordStar clone) which has emacs-like key combinations but with slightly different assignments. And because of this default I've never made a habit of using line editing commands; there's no way I can unlearn my Joe muscle memory, and over the years I've gotten into the habit of avoiding shell personalizations, to my detriment in this case.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s...
[+] [-] yodsanklai|5 years ago|reply
I'm not sure about this. For instance, I'm typing this message in a text box in my browser and I don't have access to vim keybindings. There are many cases where this happens (other example: google docs).
I do use vim whenever I can, but I'd say the most useful keybindings that one can learn are the ones from the OS.
[+] [-] freedomben|5 years ago|reply
[+] [-] pkulak|5 years ago|reply
[+] [-] mixmastamyk|5 years ago|reply
- Geany
- Sublime Text
- VS Code
- Notepad++
- micro
- ne
On top of these I usually memorize Ctrl-A and Ctrl-E for the command-line, and "i… :wq" for vim, although haven't needed the latter in a decade.
[+] [-] darintay|5 years ago|reply
Most anything that VSCode can do, you can make vim do with plugins, but it is often incredibly time consuming and finnicky to get up and running, whereas with VSCode everything "just works".
All the productivity of being able to edit text in vim, alongside the conveniences of a real, modern IDE.
[+] [-] i_love_limes|5 years ago|reply
I always loved vims movement and editing and hated it's file traversal / project management, so this is a perfect amalgamation
[+] [-] edanm|5 years ago|reply
VSCode is awesome, it provides a ton of benefits you don't get from emacs or vanilla vim. I'm really enjoying using it, and there's a chance that it will become my new "main" editor.
That said, the vim mode is not perfect. It only takes a few minutes of work before I run into a limitation of the vim mode, some binding or other that I use and that isn't replicated. More importantly, some things feel broken - there have been cases where undo didn't work properly for me, and cases where numerical arguments to commands messed things up.
That said, I've actually started taking the time to customize the vim mode in VSCode, and it's starting to pay off.
[+] [-] 7786655|5 years ago|reply
[+] [-] Keyframe|5 years ago|reply
[+] [-] nrclark|5 years ago|reply
You don't need to be a vi/vim wizard, but you should at least be able to use it a little bit. Vi is the one editor that's guaranteed to be available basically anywhere.
For working on a complex file (local to my workstation), I almost always prefer Geany or maybe VSCode (depending on the scope of the project). But I'm also semi-decent with vi, and it's saved me a lot of times on embedded systems where I need to log in via serial-console and edit some files.
It's also just faster/easier for editing the odd config-file here or there on a system that I'm logged into. Sure, I could launch a GUI and browse to it (for a local file), or maybe edit with a GUI over SSHFS or something. But if it's a small change? Vim is killer.
Maybe Emacs is better for CLI use, I'm not sure one way or the other. But it's definitely got a much smaller install-base than Vim. And proper-noun Vim has a _much_ smaller install-base than vi-compatible things generally (vim, busybox vi, etc).
[+] [-] brandonmenc|5 years ago|reply
Programmers like using vim because it feels like solving a puzzle or RTS micro'ing and/or they have already sunk a huge amount of time into it and aren't willing to walk away (which is fine, but it's not evidence that these tools are better.)
Starting fresh (i.e. no experience with an IDE or vi/emacs) there is zero productivity benefit to choosing vi or emacs over a real IDE in this day and age.
Disclaimer: I am a former vi (~5 years) and emacs (~20 years) fanatic.
[+] [-] latortuga|5 years ago|reply
Vim is great and I love it and have used it for 12 years day in and day out. But I wouldn't say it's what makes me productive, just that I got good at it and know it well.
[+] [-] edanm|5 years ago|reply
I am (was?) a heavy vim user - 10 years, a .vimrc with thousands of lines and many custom code and settings.
I can vouch that in my case, one of the reasons that I did this is because I enjoyed it. I played around with many editors before I settled on vim, and I enjoyed it immensely. vim was my main editor for many years because it was the best at editing and still is. But for sure I wouldn't have sunk so much time into it without also having fun doing it.
In the last few years, I've started experimenting with other editors/IDEs using vim mode, starting from spacemacs, and now using VSCode.
[+] [-] minerjoe|5 years ago|reply
[+] [-] Balooga|5 years ago|reply
vi/emacs will definitely still be around in 20 years. Other editors may not be.
[+] [-] n0on3|5 years ago|reply
TBH, although this might be an unpopular opinion among vim users, I don't think vim is worth for coding beyond simple scripting, a decent setup requires way too much work which defeats one of its key points. But for everything else in editing files, nothing compares.
[+] [-] gizmo686|5 years ago|reply
Also, for some reason, many modern systems still only install vi by default. If you know vim, you know vi; but it is missing enough features to be annoying.
[+] [-] notJim|5 years ago|reply
The thing I'm running into recently is that it gets very slow for large files. Unfortunately, where I work, the norm is to have files be thousands and thousands of lines long, which causes my setup which otherwise works fine to become very slow.
It's probably a plugin I'm using, but as you say, it now becomes my responsibility to figure out which one it is. Contrast this with vscode, which works fine out of the box, and already has most features built in.
[+] [-] bdamm|5 years ago|reply
[+] [-] edanm|5 years ago|reply
You know, people always say this, but I've never seen that actually happen. And I've been using vim for around 10 years, with lots of customizations. I consider myself fairly proficient (though by no means an expert).
[+] [-] auslegung|5 years ago|reply
Week 1: Complete vimtutor once a day, every day Week 2: Use Vim with minimal config, no plugins Week 3: Use Vim with minimal plugins Week 4: Compose Vim commands with verbs and nouns
[+] [-] _virtu|5 years ago|reply
The vim ecosystem reminds me of the node ecosystem. It's a choose your own adventure approach. Yes, there are wonderful and powerful tools, but it's always a shotgun of plugins to get a solution for each language you want to support. With JetBrains, I get 90% of the tooling I need for the language I'm using out of the box. The other 10% can be handled by plugins and some small configuration changes.
I'm posting this because I want to be convinced otherwise. Here are the JetBrains features that I can't live without:
[+] [-] kasajian|5 years ago|reply
It's not even good at dealing with more than one file. Yeah, I have nerd-tree and have tried explore. meh.
I'll think about it when ReSharper comes up with an add-in for VIM.
Yes, I know Visual Studio Code has VIM mode. . and Visual Studio used to (or maybe still does), but then you're outside the norm of that environment. Ever Visual Studio Code extension is tested with Visual Studio Code. But they're not all tested with Visual Studio Code in VIM mode. That's why I like to stick with defaults and the base-case.
What's needed is for VIM itself to have features beyond just editing text files. It's never going to compete with Visual Studio or Visual Studio code until VIM itself adds those features that make a viable IDE replacement. Today, it ain't.
[+] [-] d33|5 years ago|reply
https://github.com/d33tah/dotfiles/blob/master/dotfiles/vimr...
You'll also need to run:
Personally I was surprised many times how easy it was to add decent support for new languages. It really is a godsend.[+] [-] AlexSW|5 years ago|reply
I also use a buffer explorer plugin and LSP servers too (go to definitions, find references, etc.), but buffers and fzf alone can be very powerful.
[+] [-] apotatopot|5 years ago|reply
[+] [-] commandlinefan|5 years ago|reply
[+] [-] aidenn0|5 years ago|reply
[+] [-] thekelvinliu|5 years ago|reply
i stopped using tmux because now all i need to do is open a terminal buffer in a new split to multiplex. i rarely used it for sessions, but use abduco[1] for that now when i find the need.
[0]: https://github.com/mhinz/neovim-remote
[1]: https://github.com/martanne/abduco
[+] [-] jedimastert|5 years ago|reply
[+] [-] 01100011|5 years ago|reply
[+] [-] rsa25519|5 years ago|reply
Drag your mouse while pressing meta on VS Code. I certainly think Vim is powerful, and I've spent enough time in it to be able to edit a file solely via ex. But I think VS Code is making some awesome progress, too. I like using the two editors together
[+] [-] brandonmenc|5 years ago|reply
Yeah, what? Seriously?
JetBrains: command-shift-8 to toggle column select mode.
And if you forget that, just control-click and you can select it in the popup menu.
The only explanation for boneheaded statements like these are that vi/emacs nuts haven't used a modern IDE in decades.
[+] [-] com2kid|5 years ago|reply
Doesn't help that I use a Windows keyboard on Mac some days, and a Windows machine on others.
Also mice suck (but are orders of magnitude better than track pads), I always find selecting columns this way to be super finicky and I often have to do it twice to get it just right.
[+] [-] axegon_|5 years ago|reply
[+] [-] erulabs|5 years ago|reply
[+] [-] imran3740|5 years ago|reply
Someone's already made plugins that embed a Neovim instance right inside VSCode[1] and Sublime Text[2]. There's no emulation here, just straight up neovim running behind those buffers. I've tried VSCode with that plugin (though personally I like to stick to just neovim when I can), and I can say that despite some minor bugs it's been a pretty smooth experience. Even stuff like `gt` to change editor tabs is supported.
[0]: https://neovim.io/
[1]: https://github.com/asvetliakov/vscode-neovim
[2]: https://github.com/lunixbochs/actualvim
[+] [-] adsjhdashkj|5 years ago|reply
Does vscode-neovim work around this somehow?
[+] [-] andersced|5 years ago|reply
[+] [-] chipotle_coyote|5 years ago|reply
My main computer is also a Mac and I also need to copy text to and from multiple machines and the host machine, and while I don't write C++, I do write other languages on all the remote machines -- and BBEdit lets me do that a lot more easily, since it has menu commands for save/open over FTP/SFTP. But it's certainly not unique in that regard. (Personally I've found Vim's netrw implementation of this a bit clunky and never got Emacs's functionality for this working quite right, although "Never Got Emacs Working Quite Right" may be my epitaph).
[+] [-] colonwqbang|5 years ago|reply
[+] [-] haolez|5 years ago|reply
[+] [-] ropeladder|5 years ago|reply
But...
Vim bindings also feel like they have accumulated 40 years of cruft and evolved into some severely localized maxima. I'd be really interested in other attempts to do modal editing. Are there other attempts out there?
(Disclaimer: I use vim and vim bindings a lot but I am not really a vim power user.)
[+] [-] simonebrunozzi|5 years ago|reply
Years later, I started thinking that sooner or later, a simpler, better alternative would emerge.
It's 2020, and I'm still waiting.
[+] [-] austinl|5 years ago|reply
The biggest downside for me is I don't think autocomplete is on par with other IDEs (even with YouCompleteMe, which is great). To be fair, this would be a massive challenge, considering how generalized vim is vs. an IDE like Xcode — which is purpose-built for writing Swift/ObjC. I feel like half of the time in Xcode I'm just hitting tab, and the code writes itself. I want that same experience in vim.
[+] [-] major505|5 years ago|reply
That said, after use it extensive in the past, unless your editing code in a potato, for more complex work, I don't see a reason to learn advanced commands. You will be more productive with a modern text editor.
[+] [-] scythe|5 years ago|reply
- opens instantly
- does side-by-side file viewing with reasonable text size and low enough clutter for a laptop screen
- offers a great deal of editing power with no need for any extra preparation
Starting to work -- particularly at irregular times -- is much more fluid with vim. I usually need to take a deep breath before opening an IDE. Vim is just there, at my fingertips, all the time, and few competitors offer that experience.
[+] [-] Shared404|5 years ago|reply
I can't even count the times I've accidentally written :w into a document while using an editor without vim bindings.