Learning Vim incrementally (2010)(yehudakatz.com)
yehudakatz.com
Learning Vim incrementally (2010)
https://yehudakatz.com/2010/07/29/everyone-who-tried-to-convince-me-to-use-vim-was-wrong/
88 comments
No idea why you're getting downvoted
I'm very much against plugins as well, being able to reliably work on a vanilla vim install allows me to productive everywhere.
But yes, I do miss the multicursors I've learned to love on Sublime Text.
I'm very much against plugins as well, being able to reliably work on a vanilla vim install allows me to productive everywhere.
But yes, I do miss the multicursors I've learned to love on Sublime Text.
I have try to be able to use both. e.g. I know how to set up a path and hit search for files but I find FZF to be better.
I know how to use Netrw to show a file tree but I prefer the look of NerdTree.
I also often use ctags for navigation but I'm using coc.vim plugins more and more to get code aware LFP features.
Generally I try to avoid custom mappings though so I'm closer to vanilla vim when I need to be.
I know how to use Netrw to show a file tree but I prefer the look of NerdTree.
I also often use ctags for navigation but I'm using coc.vim plugins more and more to get code aware LFP features.
Generally I try to avoid custom mappings though so I'm closer to vanilla vim when I need to be.
Maybe I'm wrong... I'm a vim old timer, and have been using it for years, but I really love the plugin community in Vim, and it has gotten better and better in the last several years.
Things like 'vim-tmux-navigator' saves me several keystrokes and makes vim splits work along side tmux panes. Tim Pope's 'vim-fugitive' really helps understanding the context of the changes in a git repo, or even navigate the history of changes in a particular file. Tim Pope's vim-sleuth automatically matches the formatting of a file you open.
Some modern plugins that attach languageserver features, like Coc.vim, or Ale, are really great for code completion, intellisense, automatic formatting, and linting.
Obviously vanilla vim is powerful enough to do most anything, but, it's really fun to tailor a vim environment.
Things like 'vim-tmux-navigator' saves me several keystrokes and makes vim splits work along side tmux panes. Tim Pope's 'vim-fugitive' really helps understanding the context of the changes in a git repo, or even navigate the history of changes in a particular file. Tim Pope's vim-sleuth automatically matches the formatting of a file you open.
Some modern plugins that attach languageserver features, like Coc.vim, or Ale, are really great for code completion, intellisense, automatic formatting, and linting.
Obviously vanilla vim is powerful enough to do most anything, but, it's really fun to tailor a vim environment.
The following has been repeated quite a lot on HN, but for people who are new to vim or new to reading HN it bears repeating.
1. Go to your terminal.
2. Type in vimtutor.
3. Spend half an hour.
4. Congratulations! You are now able to survive in vim, while you're by no means a master yet, you're probably around 80 to 90% as productive in vim as with a general text-editor without plugins.
IMO it's 30 minutes well spent.
1. Go to your terminal.
2. Type in vimtutor.
3. Spend half an hour.
4. Congratulations! You are now able to survive in vim, while you're by no means a master yet, you're probably around 80 to 90% as productive in vim as with a general text-editor without plugins.
IMO it's 30 minutes well spent.
I think the point of the OP was that they don't want to have to memorise a whole bunch of new commands before they can be productive with their new editor.
This makes a lot of sense btw. Think of all the commands and shortcuts you need to know to be productive and quick in everyday programming work: OS shortcuts; terminal commands; git commands; IDE shortcuts; and now, a whole bunch of editor shortcuts _and_ commands.
And, does vim's interface help you very much with remembering what you should type in to do what? Sometimes, yes (:w(rite); :q(uit);: x(it); :w/q/x/a(ll); etc). Sometimes, not so much, no (hjkl wtf? :y? :o? Is that a smily face?).
And how much of that stuff in vimtutor are you going to use in the first week of use? 10%? 20%? 50%? The rest, you'll just forget immediately anyway. So that's half an hour that you probably can't afford and that you definitely don't need.
So taking it easy and not trying to learn a whole bunch of stuff you're not sure you need is very good advice.
This makes a lot of sense btw. Think of all the commands and shortcuts you need to know to be productive and quick in everyday programming work: OS shortcuts; terminal commands; git commands; IDE shortcuts; and now, a whole bunch of editor shortcuts _and_ commands.
And, does vim's interface help you very much with remembering what you should type in to do what? Sometimes, yes (:w(rite); :q(uit);: x(it); :w/q/x/a(ll); etc). Sometimes, not so much, no (hjkl wtf? :y? :o? Is that a smily face?).
And how much of that stuff in vimtutor are you going to use in the first week of use? 10%? 20%? 50%? The rest, you'll just forget immediately anyway. So that's half an hour that you probably can't afford and that you definitely don't need.
So taking it easy and not trying to learn a whole bunch of stuff you're not sure you need is very good advice.
Apologies for the long comment, succinct writing is tough.
I have a different opinion, but do understand your scepticism. If people would've told me this before "just type in vimtutor and 30 min. and boom you're ready" I'd have laughed at them.
As a big proponent of vimtutor, I daresay that vimtutor is taking it easy. It took me 30 minutes during a subway ride and I've tried to learn vim a couple of times, and I think I even read this article among one of those failed tries.
Yes, you learn a lot of commands, but the tutorial structures it relatively nicely. Also, they're grouped: hjkl are 4 different commands, but if you know one, you can infer the other three. The same goes for w and q. Yank and what I prefer to call "Open new line" were quite intuitive for me at the get go, but then again I had the habit of creating mnemonics.
The first 4 chapters (I think it was the first 4) already give you the super powers to survive.
Vim is indeed very unforgiving, which is why people need a tutorial.
How much stuff did I use in the first week? Well since I did the tutorial several times, I can tell from memory what I remembered initially:
The 5 essential commands:
i - Insert
ESC - Escape (aka please get me out of insert mode or whatever mode I'm in! :'( )
w - write
q - quit
q! - I really want to quit, I don't care what you do now! (and then immediately redoing the vim command with sudo vim filename.txt)
Some text editing commands (not sorted on if I'm insert or browsing mode):
dd - delete and copy (or delete and pop)
$ - goes up or down or end of line? (I still forget that)
gg - goes up or down or end of line? (I still forget that)
G - goes up or down or end of line? (I still forget that)
A - append (or small letter a)
hjkl - Home row movement, not needing to lift the finger
y - yank aka copy (as a non-native English speaker it was fun to learn that "yank" can mean copy)
x - cut
e - end of word
b - beginning of word
r - replace (not that I ever use it)
From the top of my mind, I learned about 80% of these commands back then. IMO knowing these commands makes you survivable.
Later on, I also learned a thing or two with vim visual mode. I kind of forgot that now. I vaguely remember it was something with CTRL + V or Shift + V and that you can select a block and indent it with Shift + I. I remember I went even into the vimrc file, or whatever it was called. But I decided to stick with Sublime Text and simply use this skill when I quickly need a terminal editor (oh, and also to not be annoyed by git).
As you can see, in the demonstration of my very humble knowledge, I only vaguely know what the commands do as I don't use vim every day (more like every month to touch a line quickly). But I kind of know what they do and with some quick experimentation I figured it out again.
I have the suspicion you already know vim. For other people, my suggestion is: just try vimtutor, you'd probably already have finished chapter 1 and 2 by now if you would have done vimtutor instead of reading my long comment.
I have a different opinion, but do understand your scepticism. If people would've told me this before "just type in vimtutor and 30 min. and boom you're ready" I'd have laughed at them.
As a big proponent of vimtutor, I daresay that vimtutor is taking it easy. It took me 30 minutes during a subway ride and I've tried to learn vim a couple of times, and I think I even read this article among one of those failed tries.
Yes, you learn a lot of commands, but the tutorial structures it relatively nicely. Also, they're grouped: hjkl are 4 different commands, but if you know one, you can infer the other three. The same goes for w and q. Yank and what I prefer to call "Open new line" were quite intuitive for me at the get go, but then again I had the habit of creating mnemonics.
The first 4 chapters (I think it was the first 4) already give you the super powers to survive.
Vim is indeed very unforgiving, which is why people need a tutorial.
How much stuff did I use in the first week? Well since I did the tutorial several times, I can tell from memory what I remembered initially:
The 5 essential commands:
i - Insert
ESC - Escape (aka please get me out of insert mode or whatever mode I'm in! :'( )
w - write
q - quit
q! - I really want to quit, I don't care what you do now! (and then immediately redoing the vim command with sudo vim filename.txt)
Some text editing commands (not sorted on if I'm insert or browsing mode):
dd - delete and copy (or delete and pop)
$ - goes up or down or end of line? (I still forget that)
gg - goes up or down or end of line? (I still forget that)
G - goes up or down or end of line? (I still forget that)
A - append (or small letter a)
hjkl - Home row movement, not needing to lift the finger
y - yank aka copy (as a non-native English speaker it was fun to learn that "yank" can mean copy)
x - cut
e - end of word
b - beginning of word
r - replace (not that I ever use it)
From the top of my mind, I learned about 80% of these commands back then. IMO knowing these commands makes you survivable.
Later on, I also learned a thing or two with vim visual mode. I kind of forgot that now. I vaguely remember it was something with CTRL + V or Shift + V and that you can select a block and indent it with Shift + I. I remember I went even into the vimrc file, or whatever it was called. But I decided to stick with Sublime Text and simply use this skill when I quickly need a terminal editor (oh, and also to not be annoyed by git).
As you can see, in the demonstration of my very humble knowledge, I only vaguely know what the commands do as I don't use vim every day (more like every month to touch a line quickly). But I kind of know what they do and with some quick experimentation I figured it out again.
I have the suspicion you already know vim. For other people, my suggestion is: just try vimtutor, you'd probably already have finished chapter 1 and 2 by now if you would have done vimtutor instead of reading my long comment.
One of the nice, well-thought things about $ (end of line) and its inverse, ^ (beginning of line), is they have exactly the same meaning in normal mode as they do in regular expressions (with a small caveat that ^ ignores whitespace, so it's not so much the beginning of the line as it is the beginning of text on that line).
I never thought about that. Thanks!
Yes, I already know vim- it's the only text editor I've used for the last
eight years or so [1].
OK, I accept that some users will find vimtutor helpful, like you did. On the other hand- I would never have learned to use vim if it meant I had to read 4 chapters before I could "survive" in it.
The way I learned vim was ... to not try to learn vim. This is much like the article above describes it. Before vim I was using Notepad++. At some point, I switched to vim and just did all the things I was doing in Notepad++, except I did them using vim. That meant I only had to climb the smoothest learning curve and my productivity never dropped from having to stop and search for advanced stuff.
I was a bit annoyed originally by the Mikado of escape slashes in regexes, but I got used to them reasonably quickly. Then at some point, when I needed to do more advanced stuff that I'd never have considered doing with Notepad++ [2] I looked that stuff up and learned how to do it, but only as and when I needed it.
In the first year or so I was keeping a notes file with all the weird-syntax commands that I needed with enough frequency that I wanted to keep handy, but I couldn't bother to memorise. I still occasionally consult this file, e.g. when I need to remember the syntax for look-ahead or look-behind regexes. It turns out, you can go a _long_ way without really, really having to do a lookahead.
I should say, I also tried a few vim plugins here and there, but mostly they seemed to mess up my install, so I was turned off them for good. Pretty much the only plugin I use nowadays is the excellent highlight script from the vim wiki (https://vim.fandom.com/wiki/Highlight_multiple_words). It's just perfect for highlighting logs and, er, logs.
So while I appreciate that vimtutor can be useful to some users, it is by no means the only, or the simplest, way to get to a point where you're feeling comfortable using vim.
________________
[1] The one exception is the Emacs-based editor in the Swi-Prolog IDE, which has a very good Prolog mode that actually compiles your code so it flags errors and so on. It'd take a while to do this in vim, and there's no real reason to. Although I miss being able to scroll with Ctrl+E/Y.
[2] Like using netrw to edit files directy on a remote server over a powershell remote session, which got me some impressed comments by a senior dev in my company, since everyone else just RDP'd to the server.
OK, I accept that some users will find vimtutor helpful, like you did. On the other hand- I would never have learned to use vim if it meant I had to read 4 chapters before I could "survive" in it.
The way I learned vim was ... to not try to learn vim. This is much like the article above describes it. Before vim I was using Notepad++. At some point, I switched to vim and just did all the things I was doing in Notepad++, except I did them using vim. That meant I only had to climb the smoothest learning curve and my productivity never dropped from having to stop and search for advanced stuff.
I was a bit annoyed originally by the Mikado of escape slashes in regexes, but I got used to them reasonably quickly. Then at some point, when I needed to do more advanced stuff that I'd never have considered doing with Notepad++ [2] I looked that stuff up and learned how to do it, but only as and when I needed it.
In the first year or so I was keeping a notes file with all the weird-syntax commands that I needed with enough frequency that I wanted to keep handy, but I couldn't bother to memorise. I still occasionally consult this file, e.g. when I need to remember the syntax for look-ahead or look-behind regexes. It turns out, you can go a _long_ way without really, really having to do a lookahead.
I should say, I also tried a few vim plugins here and there, but mostly they seemed to mess up my install, so I was turned off them for good. Pretty much the only plugin I use nowadays is the excellent highlight script from the vim wiki (https://vim.fandom.com/wiki/Highlight_multiple_words). It's just perfect for highlighting logs and, er, logs.
So while I appreciate that vimtutor can be useful to some users, it is by no means the only, or the simplest, way to get to a point where you're feeling comfortable using vim.
________________
[1] The one exception is the Emacs-based editor in the Swi-Prolog IDE, which has a very good Prolog mode that actually compiles your code so it flags errors and so on. It'd take a while to do this in vim, and there's no real reason to. Although I miss being able to scroll with Ctrl+E/Y.
[2] Like using netrw to edit files directy on a remote server over a powershell remote session, which got me some impressed comments by a senior dev in my company, since everyone else just RDP'd to the server.
That's the simplest and best starting suggestion.
I'd follow it with watching some editing videos on http://vimcasts.org/ and by reading Practical Vim[1] gives a really good set of editing recipes in "pure" vim without plugins.
Finally I'd also suggest the follow up Modern Vim find out about plugins and LSP support.[2]
[1] https://pragprog.com/book/dnvim/practical-vim
[2] https://pragprog.com/book/modvim/modern-vim
I'd follow it with watching some editing videos on http://vimcasts.org/ and by reading Practical Vim[1] gives a really good set of editing recipes in "pure" vim without plugins.
Finally I'd also suggest the follow up Modern Vim find out about plugins and LSP support.[2]
[1] https://pragprog.com/book/dnvim/practical-vim
[2] https://pragprog.com/book/modvim/modern-vim
[deleted]
The post is from 2010, today in 2019, I'd say that first step could be to install a vim extension in your already existing IDE/editor, VSCode and Idea have good enough vim plugins to start learning insert mode and moving around, and even allow you to search and replace :%s/termA/termB/g
You can also play Vim Adventures[1] if you want to be even more playful.
[1] https://vim-adventures.com/
[1] https://vim-adventures.com/
Unfortunately I've found that vim modes for various editors are good enough to fool you so you keep using them, but not good enough to not frustrate you with the differences. In PyCharm, for example, I have no idea how to use any keyboard shortcuts with vim mode on, since vim then absorbs the keys pressed and I lose all keyboard access to the functionality.
I have the same experience, but I'm yet to decide what is worse: weak vi-mode where it collapses straight away(no count support fex), or strong support where it fools you for long enough to catch you out when you're fully in the flow.
My go-to example for strong support is emacs' evil-mode¹, it takes a lot for it to break down. For example, it even supports things like the expression register² but then requires an elisp expression.
1. https://bitbucket.org/lyro/evil/wiki/Home 2. https://vimhelp.org/insert.txt.html#i_CTRL-R_%3D
Edit: I'm pointing out where it has fallen down for me, not complaining that the devs haven't implemented a full vimscript interpreter to attach to that binding. I love evil.
My go-to example for strong support is emacs' evil-mode¹, it takes a lot for it to break down. For example, it even supports things like the expression register² but then requires an elisp expression.
1. https://bitbucket.org/lyro/evil/wiki/Home 2. https://vimhelp.org/insert.txt.html#i_CTRL-R_%3D
Edit: I'm pointing out where it has fallen down for me, not complaining that the devs haven't implemented a full vimscript interpreter to attach to that binding. I love evil.
The great thing about spacemacs/evil is that generally all the standard emacs bindings work how you'd expect them to. I can still M-x and get access to everything emacs.
Simply not true. Actually Jetbrains IDEs have IMO one of the best if not the best VIM emulations in all IDEs, IdeaVIM is awesome.
For example, you can have your own custom "vimrc", they call it ".ideavimrc" which can also read your normal .vimrc but I prefer to keep it separate.
Once in the .ideavimrc, ideavim has emulation for probably the most popular vim plugin (vim-surround) and also vim-multiple-cursor and commentary.vim plugins, you just have to enable them... set surround, etc... see more at: https://github.com/JetBrains/ideavim
But to me the best part of it is doing my own keymappings to execute IDE actions which sometimes don't even have a shortcut or menu and are just accessible by "mouse"
you can do stuff like:
:map <leader>r :action Refactorings.QuickListPopupAction<CR> (refactor this popup) :map <leader>z :action ChangesView.Revert<CR> (git revert dialog) :map <leader>f :action Tool_External Tools_Flake8 (run flake8 external tool)
supports imap, vmap as well in case u just want to trigger in those modes.
etc... this will let you use the ANY IDE action with just the keyboard and most dialogs in jetbrains IDE support CTRL+N/P for next/prev navigation in panes... not to mention you can filter most of them just by typing whatever
The fact IdeaVIM exists is probably the biggest reason I use and pay for Jetbrains IDEs, all the VIM goodness + IDE convenience.
For example, you can have your own custom "vimrc", they call it ".ideavimrc" which can also read your normal .vimrc but I prefer to keep it separate.
Once in the .ideavimrc, ideavim has emulation for probably the most popular vim plugin (vim-surround) and also vim-multiple-cursor and commentary.vim plugins, you just have to enable them... set surround, etc... see more at: https://github.com/JetBrains/ideavim
But to me the best part of it is doing my own keymappings to execute IDE actions which sometimes don't even have a shortcut or menu and are just accessible by "mouse"
you can do stuff like:
:map <leader>r :action Refactorings.QuickListPopupAction<CR> (refactor this popup) :map <leader>z :action ChangesView.Revert<CR> (git revert dialog) :map <leader>f :action Tool_External Tools_Flake8 (run flake8 external tool)
supports imap, vmap as well in case u just want to trigger in those modes.
etc... this will let you use the ANY IDE action with just the keyboard and most dialogs in jetbrains IDE support CTRL+N/P for next/prev navigation in panes... not to mention you can filter most of them just by typing whatever
The fact IdeaVIM exists is probably the biggest reason I use and pay for Jetbrains IDEs, all the VIM goodness + IDE convenience.
I had no idea any of these features existed. In particular the story) support for vimrc and the surround plug in are game changers.
The vim extension for VSCode even has macro recording!
Anyone here who uses Nvim-R?
you mean vimR?
https://github.com/jalvesaq/Nvim-R
Is vimR better?
Is vimR better?
Oh, completely different. The one I meant was https://github.com/qvacua/vimr. Different things . Sorry for that.
I'm convinced that people who use solely vim/emacs started off before there were any good GUI editors and now have too much momentum. I'm not that old, but I frequently spend time on headless *nix boxes, so I use vim all the time and love it. I have a portable .vimrc that I take around with me because I have spent so much time that I want to configure things the way I like them.
Despite my love of vim, on the desktop, I fall back to gedit or Notepad++.
Vim and Emacs are great editors when you're SSH'd to a headless server, but they will not replace an IDE (or even TextMate). That is completely ridiculous.
Despite my love of vim, on the desktop, I fall back to gedit or Notepad++.
Vim and Emacs are great editors when you're SSH'd to a headless server, but they will not replace an IDE (or even TextMate). That is completely ridiculous.
I'm the counterpoint to that belief. I started programming professionally in 2010, learned vim around 2012. My work environment was just better suited for a command line editor and it was nano, vim or emacs. Vim won. Since then, I'll have a constant itch to get vim bindings in whatever editor I'm using.
At the time I switched, I'd been using Notepad++ and loved it. These days, my graphical editor is Sublime (of course with vintage mode enabled).
Vim with just a handful of plugins is a complete IDE. Vim alone is an editor.
At the time I switched, I'd been using Notepad++ and loved it. These days, my graphical editor is Sublime (of course with vintage mode enabled).
Vim with just a handful of plugins is a complete IDE. Vim alone is an editor.
Vim was before my time, but I learned how to use it after seeing in videos how blazingly fast people could edit text inside vim. I had already put hundreds of hours into Visual Studio by this point, so I installed a vim emulation plugin and haven't looked back since. I've never used vim-proper as my daily driver, but I can use it well enough thanks to cutting my teeth with vim emulation plugins in more modern editors.
You know what's funny? ed is the standard text editor. Not vim. Not emacs. Not nano. ed.
So you should count yourself lucky that you can use vim on your headless servers -as I can, and I do count myself lucky, because I have seen the horrors of trying to edit files with ed, on Z/Os, inside TSO, on a mainframe. And it was not cute and cuddly like mistakingly retrieving xa! on the command line in vim and pressing enter, when you're not done yet with your changes and you don't have a copy. It was much, much worse.
So you should count yourself lucky that you can use vim on your headless servers -as I can, and I do count myself lucky, because I have seen the horrors of trying to edit files with ed, on Z/Os, inside TSO, on a mainframe. And it was not cute and cuddly like mistakingly retrieving xa! on the command line in vim and pressing enter, when you're not done yet with your changes and you don't have a copy. It was much, much worse.
I started programming professionally in 2015. I’ve tried all the “big name” GUI editors: Eclipse, IntelliJ, Sublime, Atom, Notepad++, VSCode. Now I use vim full time and I love it.
I grant that vim is not the most user friendly, but if you take the time to learn it it can do almost everything most IDEs do, including symbol based navigation, “fuzzy finding”, search-and-replace, etc. And that’s just native Vim — some plugins make these features completely comparable with (or better than!) IDEs.
I’m convinced that modal editing is the most efficient way to edit text, and vim’s biggest feature is how tightly integrated it is with the terminal. In a GUI editor, using a terminal means either using a subpar integrated terminal (like in VSCode) or switching over to my terminal emulator to run some commands and then switching back. Since I spend a lot of my time in the terminal, this is a big deal for me.
I grant that vim is not the most user friendly, but if you take the time to learn it it can do almost everything most IDEs do, including symbol based navigation, “fuzzy finding”, search-and-replace, etc. And that’s just native Vim — some plugins make these features completely comparable with (or better than!) IDEs.
I’m convinced that modal editing is the most efficient way to edit text, and vim’s biggest feature is how tightly integrated it is with the terminal. In a GUI editor, using a terminal means either using a subpar integrated terminal (like in VSCode) or switching over to my terminal emulator to run some commands and then switching back. Since I spend a lot of my time in the terminal, this is a big deal for me.
Really curious to hear why vim cannot replace an IDE or TextMate? Maybe it depends on your very specific use case? I certainly replaced my IDE(s) with vim and some plugins.
I'm a vim user, certainly one who was alive long after "good GUI editors." My first programming was done in Visual Basic over 20 years ago.
I'm a vim user, certainly one who was alive long after "good GUI editors." My first programming was done in Visual Basic over 20 years ago.
Using Eclipse, any jetbrains stuff, android studio, and xcode (even GNOME builder!) is super helpful for me. They have completion features, a robust set of build tools, and everything in one window with all the controls visible. I love the autocompletion, console, build environment, and when I think about the time it took me to get my .vimrc to where it is now, just for writing text and basic scripts, I shudder to think of how much I'd have to add to make it even close to something like Eclipse.
I am hobbyist programmer and a parent, so I don't get a lot of time to do programming these days. When I do I don't like fiddling my half-baked tmux/vim setup. I just wanna write code. So I use IDEs.
I am hobbyist programmer and a parent, so I don't get a lot of time to do programming these days. When I do I don't like fiddling my half-baked tmux/vim setup. I just wanna write code. So I use IDEs.
>I shudder to think of how much I'd have to add to make it even close to something like Eclipse.
It depends on what you use in Eclipse, really. But vim has plugins to do things like autocompletion, there's many ways to access console (:term), etc. It's all done through plugins, you just use whatever plugin manager to add them. It's very simple.
>I am hobbyist programmer and a parent, so I don't get a lot of time to do programming these days. When I do I don't like fiddling my half-baked tmux/vim setup. I just wanna write code. So I use IDEs.
Me too, but the day or two it took to get vim setup to function as an IDE also meant I had all the power that comes along with vim. For me it is well worth the time investment of a few hours for something I'll use for years and years and be more productive than using Eclipse. And allows me to go between my normal text editor and IDE and share all my keybindings and workflows.
I think a good trade off would be something like a vim plugin for Eclipse. PyCharm for example has IdeaVIM which is a plugin that brings a lot of the power of vim to that IDE.
I just couldn't give up all the power of vim just for the out-of-the-box IDE features like autocomplete when I can just add them to vim.
It depends on what you use in Eclipse, really. But vim has plugins to do things like autocompletion, there's many ways to access console (:term), etc. It's all done through plugins, you just use whatever plugin manager to add them. It's very simple.
>I am hobbyist programmer and a parent, so I don't get a lot of time to do programming these days. When I do I don't like fiddling my half-baked tmux/vim setup. I just wanna write code. So I use IDEs.
Me too, but the day or two it took to get vim setup to function as an IDE also meant I had all the power that comes along with vim. For me it is well worth the time investment of a few hours for something I'll use for years and years and be more productive than using Eclipse. And allows me to go between my normal text editor and IDE and share all my keybindings and workflows.
I think a good trade off would be something like a vim plugin for Eclipse. PyCharm for example has IdeaVIM which is a plugin that brings a lot of the power of vim to that IDE.
I just couldn't give up all the power of vim just for the out-of-the-box IDE features like autocomplete when I can just add them to vim.
I started learning vim/emacs two years ago. I don't regret it at all and I use them both daily, even as IDEs. They're fantastic tools.
Hello my friend. I started using Emacs two years ago. Couldn’t be happpier. It’s an awesome a tool.
What features are you missing? Are there no plugins for them?
I started learning Vim keybindings (on Spacemacs) when my extensive 8h/day use of the mouse had becoming painful. Some days I could barely move some of my right hand fingers.
One day I had enough, I started the Vimtutor process and never looked back. No more pain since.
One day I had enough, I started the Vimtutor process and never looked back. No more pain since.
I agree with the article, but I'd like to add another early step: Understand that Vim's normal-mode commands are like a language with nouns and verbs. You can mix and match most nouns (motions) with most verbs (actions). So when you already know 5 motions, learning a new action actually means learning 5 action-motion combinations at once.
With this in mind, observe yourself as you work and notice which motions and actions you need most (like `ci"` in the article). Focus on these at first for those sweet sweet quick wins.
With this in mind, observe yourself as you work and notice which motions and actions you need most (like `ci"` in the article). Focus on these at first for those sweet sweet quick wins.
I keep reading about productivity on vi vs other browsers. That's cool, however the thing that makes me want to use vi with proficiency is another though: availability. I spend a lot of time in ssh or docker sessions and not knowing vi can severely hinder my job.
The thing is, if you were a user of multiple different UNIX systems the previous century, it was much the same - vi was the only editor installed out of the box on all of Solaris, BSD, Tru64, AIX, HP-UX, Linux etc. So if you were frequently moving between them as some of us were, you wouldn't get very far if you didn't know at least the basics of vi.
There are two (non-exclusive) camps for vim use.
Developer and Admin.
Most of the discussion here focuses on the dev-side of things naturally; but I want to touch on the Admin/sysop side.
If you are just starting out editing config files there is very little benefit to using vim over some more simple (i.e. nano)
Example: Editing an sshd_config file. Scenerio: You want to change the default port number that sshd is listening to. Both nano and vim make this singular task very easy and quick. As far as speed goes, I'd say they are close or equal to each other to finish this task.
Where vim really shines is for larger and more 'annoying' tasks.
Example: You need to iterate out a list of incrementing IPs for another service.
But in my experience the hands-down "it doesn't get better then this" 'Admin use' of vim is this: editing YAML files (whitespace is evil, OMG why?!?) vim can be configured to convert your tabs to spaces and all pain is ended in the universe.
Little things add up. For the odd small job, you might not see an improvement over a 'dumb' editor like nano; but the skills you learn on the small things translate into big improvements on the big jobs.
P.S. Being able to edit your editor is a HUGE benefit too. My company wants us to keep detailed track of our time-spent on each project. So I added a hotkey (F5) to input the date/time-stamp whenever I start/stop a task.
Consider this analogy, nobody needs to modify their .bashrc file or create custom aliases. But look at how much you suffer when your customizations are not there. You don't need to use anything more then nano, but the improvements scale exponentially when you do.
Most of the discussion here focuses on the dev-side of things naturally; but I want to touch on the Admin/sysop side.
If you are just starting out editing config files there is very little benefit to using vim over some more simple (i.e. nano)
Example: Editing an sshd_config file. Scenerio: You want to change the default port number that sshd is listening to. Both nano and vim make this singular task very easy and quick. As far as speed goes, I'd say they are close or equal to each other to finish this task.
Where vim really shines is for larger and more 'annoying' tasks.
Example: You need to iterate out a list of incrementing IPs for another service.
e.g.
192.168.0.1
192.168.0.2
192.168.0.3
...etc...
192.168.0.254
But in my experience the hands-down "it doesn't get better then this" 'Admin use' of vim is this: editing YAML files (whitespace is evil, OMG why?!?) vim can be configured to convert your tabs to spaces and all pain is ended in the universe.
Little things add up. For the odd small job, you might not see an improvement over a 'dumb' editor like nano; but the skills you learn on the small things translate into big improvements on the big jobs.
P.S. Being able to edit your editor is a HUGE benefit too. My company wants us to keep detailed track of our time-spent on each project. So I added a hotkey (F5) to input the date/time-stamp whenever I start/stop a task.
Consider this analogy, nobody needs to modify their .bashrc file or create custom aliases. But look at how much you suffer when your customizations are not there. You don't need to use anything more then nano, but the improvements scale exponentially when you do.
> vim can be configured to convert your tabs to spaces and all pain is ended in the universe.
Every editor more advanced than notepad can be set up to do this.
Personally I don't want to do this for every single text file format I might come across.
Being able to add weird, personal features does sound cool though.
Every editor more advanced than notepad can be set up to do this.
Personally I don't want to do this for every single text file format I might come across.
Being able to add weird, personal features does sound cool though.
When I switched to Vim, I was at 1/3 of my usual productivity for the first week, and I think at about 1/2 for the first month - author is completely true about that. However, since then, I've been so much more productive over next 7 years that it had definetly been a good decision.
And I don't even use Vim now! Visual Studio, VS Code, all JetBrain editors have competent vim emulation plugins, so the core of my ehnanced productivity, the core and most important feature of Vim, is still paying off.
I just wish I had a spare year to learn and configure Emacs. (Yes, I have tried Spacemacs and other options, many times, and it was so confusing every time that I only believe in learning Emacs from absolute basics withut any plugins now).
And I don't even use Vim now! Visual Studio, VS Code, all JetBrain editors have competent vim emulation plugins, so the core of my ehnanced productivity, the core and most important feature of Vim, is still paying off.
I just wish I had a spare year to learn and configure Emacs. (Yes, I have tried Spacemacs and other options, many times, and it was so confusing every time that I only believe in learning Emacs from absolute basics withut any plugins now).
Wait, VS/Code both have vi emulation plugins? I wish I knew this a couple of years ago ...
Any modern editor with a decent plugin ecosystem has one, and while VS/Code is not ideal, it's certainly workable.
Good to know, thankyou. I usually only use VS on Windows for C++ with Unreal Engine, usually I'm a Linux/BSD minimalist who uses vim.
I wonder how well the vi plugin for VS works alongside Visual Assist X, which is the only plugin I currently use for VS. I'll have to give it a shot when I get some time.
I wonder how well the vi plugin for VS works alongside Visual Assist X, which is the only plugin I currently use for VS. I'll have to give it a shot when I get some time.
Never used Virtual Assist X, but the plugin for VS (not VS Code, just the good old VS) is one of the best Vim plugins out there.
> To those who would say "that's obvious; of course you learn vim incrementally", I would simply say that having spoken to a number of vim users in the past, I never got that advice. Instead, I got a lot of advice about turning off my arrow keys, disallowing the use of the mouse, and learning the (MORE EFFICIENT!!!) vim ways to do everything, all at once
Ugh, this.
Arrow keys have been invented for a reason, they're good and intuitive and there's absolutely nothing wrong with using them. Same with the mouse.
The "pure" VIM ways are more efficient than ed. They're maybe more efficient some 10% of times you actually need some specific thing. But they're not better than a visual editor.
Ugh, this.
Arrow keys have been invented for a reason, they're good and intuitive and there's absolutely nothing wrong with using them. Same with the mouse.
The "pure" VIM ways are more efficient than ed. They're maybe more efficient some 10% of times you actually need some specific thing. But they're not better than a visual editor.
"Pure" vim supports cursor keys, mouse, windows, syntax highlighting, fuzzy searching for files, filetree and a whole host of other features without the need for plugins.
In what way is Vim not a "visual editor"?
The main problem with using Vim is that you will spend a bit of time explaining to those that don't know it very well that it's actually perfectly capable of doing the thing they are using as justification that you should switch to their current favourite IDE/editor... :P
In what way is Vim not a "visual editor"?
The main problem with using Vim is that you will spend a bit of time explaining to those that don't know it very well that it's actually perfectly capable of doing the thing they are using as justification that you should switch to their current favourite IDE/editor... :P
I config vim to have a slightly different semantic for arrow keys vs hjkl. I leave hjkl as-is, and then make arrow keys move across visible screen lines. So if there is a long line that wraps, the down arrow moves down one visible line (so technically still within the long line), and j moves to the next actual line in the file. Handy.
map <up> gk
imap <up> <c-o>gk
map <down> gj
imap <down> <c-o>gj
map <up> gk
imap <up> <c-o>gk
map <down> gj
imap <down> <c-o>gj
Learning a good editor is an investment. You sacrifice some productivity and time now for a massive return on your investment later. Stating the obvious, I know, but so is this article.
True. I was using mcedit for quite a while, until I one day had a short contract with one of the better known Czech programers and saw vim in action in skilled hands. It looked like magic.
I started learning it shortly after, despite being in time press at the time. It helped immensly. Just navigating around the code was amazing. Macros, repetition of the last edit action, increment/decrement a first number after the cursor, block editing, lot of tiny stuff that is just so good when combined.
I even wrote a bunch of vim code to help writing GObject C code, when it was still boilerplate heavy back in 2006.
I started learning it shortly after, despite being in time press at the time. It helped immensly. Just navigating around the code was amazing. Macros, repetition of the last edit action, increment/decrement a first number after the cursor, block editing, lot of tiny stuff that is just so good when combined.
I even wrote a bunch of vim code to help writing GObject C code, when it was still boilerplate heavy back in 2006.
>> Turn off your arrow keys.
This has gotta be the worse piece of advice I've ever heard in my life, second only to "why don't you march towards my line?" [1]. I've been using Vim for umm, eight years? Thereabouts. I never turn off my arrow keys. How much time are you supposed to save like that? Milliseconds? You go much faster with B, E, Crl+Y, Crl+D anyway.
Just misguided advice from otherwise well-meaning folks, that's all.
Edit: btw, how do you go through your recent command history on vim without up and down arrow? Do you have to q: and navigate with hjkl every single time? Is that more productive than pressing up arrow three or four times?
_____________
[1] Sorry guys, Warhammer Fantasy Battles reference there. See, I got a shooty Dwarf army, he's got a shooty Empire army, so we're standing just outside each other's range and scream insults at each other. His light cav mauls itself on my Slayers trying to flank my Thunderers (yeah, I don't know what he was thinking, either). He's got a Steam Tank, but I got a Lord on a shield (with a metric shitton of runes) protected by a regiment of Ironbreakers (with a metric shitton of runes) on the Tank's side. So noone's going anywhere in a hurry. So, by way of friendly advice, he says "why don't you march towards my line?". Yeah, right. So your Sniper can pick out my Lord and your Tank and Knights can sanswich my guys? You kiddin'?
Btw, he did win anyway. It turns out you gotta make _a lot_ of saves against a well-designed Steam Tank. Also, I suck at aiming artillery. But, come on. "Walk towards my line"? Do I look like an Elf or something?
This has gotta be the worse piece of advice I've ever heard in my life, second only to "why don't you march towards my line?" [1]. I've been using Vim for umm, eight years? Thereabouts. I never turn off my arrow keys. How much time are you supposed to save like that? Milliseconds? You go much faster with B, E, Crl+Y, Crl+D anyway.
Just misguided advice from otherwise well-meaning folks, that's all.
Edit: btw, how do you go through your recent command history on vim without up and down arrow? Do you have to q: and navigate with hjkl every single time? Is that more productive than pressing up arrow three or four times?
_____________
[1] Sorry guys, Warhammer Fantasy Battles reference there. See, I got a shooty Dwarf army, he's got a shooty Empire army, so we're standing just outside each other's range and scream insults at each other. His light cav mauls itself on my Slayers trying to flank my Thunderers (yeah, I don't know what he was thinking, either). He's got a Steam Tank, but I got a Lord on a shield (with a metric shitton of runes) protected by a regiment of Ironbreakers (with a metric shitton of runes) on the Tank's side. So noone's going anywhere in a hurry. So, by way of friendly advice, he says "why don't you march towards my line?". Yeah, right. So your Sniper can pick out my Lord and your Tank and Knights can sanswich my guys? You kiddin'?
Btw, he did win anyway. It turns out you gotta make _a lot_ of saves against a well-designed Steam Tank. Also, I suck at aiming artillery. But, come on. "Walk towards my line"? Do I look like an Elf or something?
I read that piece of advice when I started using Vim, and I'm very happy i did exactly that. If you're skittish about using Vim in the first place, then sure, it's a pretty bad idea to tell someone to disable arrow keys, but for someone that's determined to learn how to use Vim, it's great advice.
The point isn't to save time (though using hjkl does that for sure), it's to make sure your hands never leave the home row, which they ideally shouldn't do very often when using vim. It makes them more natural to use for composition: "c3h" is much cleaner than "c3<left arrow key>".
Also: if you become an "intermediate/advanced" user, you use these keys much more rarely anyway: I use "w" and "b" far more often than "h" and "l" to move inside of a line, as an example. Breaking your dependency on arrow keys makes this transition easier.
Besides, it frees up four arrow keys on your keyboard up to do all sorts of fun stuff with! I have mine bound to switching windows (so "left arrow key" is moves focus one window to the left), and with modifiers they create window splits. Makes using windows in Vim a breeze!
The point isn't to save time (though using hjkl does that for sure), it's to make sure your hands never leave the home row, which they ideally shouldn't do very often when using vim. It makes them more natural to use for composition: "c3h" is much cleaner than "c3<left arrow key>".
Also: if you become an "intermediate/advanced" user, you use these keys much more rarely anyway: I use "w" and "b" far more often than "h" and "l" to move inside of a line, as an example. Breaking your dependency on arrow keys makes this transition easier.
Besides, it frees up four arrow keys on your keyboard up to do all sorts of fun stuff with! I have mine bound to switching windows (so "left arrow key" is moves focus one window to the left), and with modifiers they create window splits. Makes using windows in Vim a breeze!
Thanks - bu I don't get the "never leave the home row" point. My fingers constantly leave the home row- to press backspace, to press Alt-tab, to press Fn and a function key to turn volume or brightness up or down on my laptop, to scratch my nose, to grab my coffee cup etc etc.
Anyway if you've bound your arrow keys to switching windows (and if you're anything like me you have a two or three windows per tab, and a bazillion of tabs, open at any one time) then your fingers do leave the home row to go to the arrow keys anyway. So what's the point?
So, sorry but I don't agree that most users would save any significant time with disabling their arrow keys. Perhaps some users would - but that should be left to each individual user. Me, I'm used to navigating around lines with the arrow keys, I abhor hkjl navigation (I even use the arrow keys on my numpad in Nethack) and I'm perfectly comfortable using vim as my only text editor since 2011 or thereabouts, when I first picked it up.
Anyway if you've bound your arrow keys to switching windows (and if you're anything like me you have a two or three windows per tab, and a bazillion of tabs, open at any one time) then your fingers do leave the home row to go to the arrow keys anyway. So what's the point?
So, sorry but I don't agree that most users would save any significant time with disabling their arrow keys. Perhaps some users would - but that should be left to each individual user. Me, I'm used to navigating around lines with the arrow keys, I abhor hkjl navigation (I even use the arrow keys on my numpad in Nethack) and I'm perfectly comfortable using vim as my only text editor since 2011 or thereabouts, when I first picked it up.
The idea is that your fingers should leave the home row as little as possible while editing. I'm not saying that you should glue your hands to your desk, I'm saying that while in the flow of editing, your hands should remain in one place.
Regular typing provides an instructive example here. Try typing a long sentence right now. If you're a touch typist, you can notice that your fingers very rarely leave the home row. Even if you're pressing shift or enter, you can basically just stretch your hand a little bit, but you can reach all the letter keys and the spacebar without moving your hands. You get into a flow where your hands remain basically fixed and the typing just flows out of you very comfortably (I'm doing it right now).
However, if you decide you need to use the arrow keys, you need to move your right hand quite a distance, and it interrupts the "typing" flow. Keyboards are designed to make this comfortable, that's why there's those little nubbins on F and J so that you always know where your home row is and where your hands are inside of it.
One of the ideas with Vim's editing commands is that editing text should become as natural as typing text is, since that's what you're doing most of the time as a coder. Imagine typing regularly and having to move your entire right hand every fifth keystroke. It would be pretty terrible.
I can personally attest that it works, and that I've very glad I rid myself of those arrow keys for regular editing. Moving to a different window doesn't happen in the middle of the "flow" (just like Alt-Tab, or changing volume or whatever doesn't), so it's fine to use them for that.
I can tell you're pretty set in your ways of how to use Vim, and that's fine: if you want to use the arrow keys, go ahead! There's no law against it, use Vim however you like. But what you're saying is essentially "all those people who say it's helpful not to use the arrow keys are lying or delusional!" I'm here to tell you that we're not. It really does work really well for us.
Regular typing provides an instructive example here. Try typing a long sentence right now. If you're a touch typist, you can notice that your fingers very rarely leave the home row. Even if you're pressing shift or enter, you can basically just stretch your hand a little bit, but you can reach all the letter keys and the spacebar without moving your hands. You get into a flow where your hands remain basically fixed and the typing just flows out of you very comfortably (I'm doing it right now).
However, if you decide you need to use the arrow keys, you need to move your right hand quite a distance, and it interrupts the "typing" flow. Keyboards are designed to make this comfortable, that's why there's those little nubbins on F and J so that you always know where your home row is and where your hands are inside of it.
One of the ideas with Vim's editing commands is that editing text should become as natural as typing text is, since that's what you're doing most of the time as a coder. Imagine typing regularly and having to move your entire right hand every fifth keystroke. It would be pretty terrible.
I can personally attest that it works, and that I've very glad I rid myself of those arrow keys for regular editing. Moving to a different window doesn't happen in the middle of the "flow" (just like Alt-Tab, or changing volume or whatever doesn't), so it's fine to use them for that.
I can tell you're pretty set in your ways of how to use Vim, and that's fine: if you want to use the arrow keys, go ahead! There's no law against it, use Vim however you like. But what you're saying is essentially "all those people who say it's helpful not to use the arrow keys are lying or delusional!" I'm here to tell you that we're not. It really does work really well for us.
cnoremap <C-P> <Up>
cnoremap <C-N> <Down>
One of the possibilities for people who already used sublime or vscode is giving a try "Oni Editor", it is based on neovim and Also have a really nice tutorial section which you can collect some achievements :
https://github.com/onivim/oni
The best part of learning Vim is being able to load it into almost all IDEs such as Eclipse and VS Code. Even though those implementations are incomplete and slow versus stock vim, it makes navigating and modifying text much easier.
I just wish there were better guides managing plug ins for Vim in Windows! I have trouble with the new Vim 8 plug in system.
I just wish there were better guides managing plug ins for Vim in Windows! I have trouble with the new Vim 8 plug in system.
You could install WSL and have native VIM in bash in a distro, with the normal Linux package management solution.
I have tried this, and it was very slow. I have had better luck with gvim or neovim-qt
Vim is quite nice, but also quite... old-fashioned?
I use vanilla vim as my main editor. Today I had to search for some text verbatim, and I don't think there's a way to do this in vim: It treats everything as a regex. I'll also happily use mouse support, and really hate the bad support for the clipboard in vim. I have spend multiple afternoons on getting this to work properly and it still doesn't. So sometimes you just have to take your loss and use another editor for something.
I use vanilla vim as my main editor. Today I had to search for some text verbatim, and I don't think there's a way to do this in vim: It treats everything as a regex. I'll also happily use mouse support, and really hate the bad support for the clipboard in vim. I have spend multiple afternoons on getting this to work properly and it still doesn't. So sometimes you just have to take your loss and use another editor for something.
treats everything as a regex by default but you can turn it off easily... /\Vwhatever... see :help \V
you can also use \< and \> (beginning of word, end of word) for easier phrase matching... /\<my phrase\>
you can also use \< and \> (beginning of word, end of word) for easier phrase matching... /\<my phrase\>
You can search for a string verbatim, but you have to remember to escape special characters. Is that what you mean? That the special characters have to be escaped?
[deleted]
ok, i'll bite: you need to learn vim if you are ever going to edit stuff remotely on a vanilla unix/linux/bsd server
I never knew you could use a mouse with vim. I've only ever used it in a terminal session. I can't understand why anyone would use an editor designed for a terminal if they have a GUI.
[Actually I mainly use vi, but I believe it's the same program]
[Actually I mainly use vi, but I believe it's the same program]
Many people, myself included, prefer to work from the command line over navigating through highly constrained, clumsy GUIs. For those people, an editor designed for the terminal is a feature, not a bug.
Point taken; I'll start a terminal to launch vi over using a GUI-based editor.
I like many of the Jetbrains editors; but for a small job, if I don't have Idea running, it's quicker to launch a terminal.
I like many of the Jetbrains editors; but for a small job, if I don't have Idea running, it's quicker to launch a terminal.
I think the authors use of MacVim makes mouse integration better supported than terminal vim.
It's useful for resizing splits and scrolling.
I switched to vim I was unproductive for days and frustrated. Then I realised I don't have to go thorough this pain there are so many great IDE's out there. 10 years later I am still super productive and don't use vim.
Vim isn't a silver bullet to productivity. Here's a parallel story:
I tried Emacs. I was frustrated and confused and felt stupid. Then I realized I had so many other tools at my disposal, I'd just use those instead. Here I am, 10 years later, happy and not feeling stupid at all! ...but I don't know Emacs.
And don't feel compelled to offer my experience on Emacs other than I struggled to learn it, but plenty seem to find it amazingly powerful. Good for them.
I tried Emacs. I was frustrated and confused and felt stupid. Then I realized I had so many other tools at my disposal, I'd just use those instead. Here I am, 10 years later, happy and not feeling stupid at all! ...but I don't know Emacs.
And don't feel compelled to offer my experience on Emacs other than I struggled to learn it, but plenty seem to find it amazingly powerful. Good for them.
vim is still the best text editor, our whole family uses it for daily work
Haha! I love it! Family that VIMs together...
There is probably an eccentric uncle who uses Emacs though!
I've been using Vim for over 20 years yet every time I read an article like this I learn something new. How did I not know about `ci "` until now?!
I can do the very basics of VIM (like exit it).
Can anyone tell me what I would gain over Pycharm (when most of my work is done there) as the learning curve seems steep?
Can anyone tell me what I would gain over Pycharm (when most of my work is done there) as the learning curve seems steep?
As for what do you gain, it's basically the same jump as copypasting by using ctrl+c/ ctrl+v vs. using your mouse to go to the top bar and clicking edit-> copy then edit->paste.
What I mean is that it's one of those computer skills that, after you learn it, even watching over the shoulder of someone who doesn't use it is painful.
As for vim vs pycharm, I wouldn't advise to switch. I would advice to find vim emulation for your current editor (vscode's is superb).
What I mean is that it's one of those computer skills that, after you learn it, even watching over the shoulder of someone who doesn't use it is painful.
As for vim vs pycharm, I wouldn't advise to switch. I would advice to find vim emulation for your current editor (vscode's is superb).
The main benefit is that the effort to learn Vim is transferrable to other programming languages and environments. Editing a config file over SSH is the same as working with Python is the same as working with Javascript.
This gets especially convenient if you work with multi-language projects, where you would otherwise find yourself switching between programming environments for a single task.
This gets especially convenient if you work with multi-language projects, where you would otherwise find yourself switching between programming environments for a single task.
I think this is possibly the wrong way to look at it.
Both Pycharm (and the JetBrains core IDE) and Vim have large feature sets and those feature sets can be extended via plugins. So saying what you would gain from one to the other is not straight forward. You gain some things and loose others.
For example Vim keeps it's undo system as a tree whereas most GUI apps keep their undo commands as a stack.
i.e. if you have series of edits and you undo 2 and then make a new change the other two edits are lost. In Vim they aren't, the tree of edits can be navigated at will.
Assuming that undo tree is a useful feature to you (it is for me) I'd have to do a good search of Pycharm plugins before I can say it's a definite advantage of Vim.
Equally you might find that Pycharm has some code aware feature that Vim can't provide via an LSP plugin or VS Code extension in which case you'd want to stay using Pycharm.
Both Pycharm (and the JetBrains core IDE) and Vim have large feature sets and those feature sets can be extended via plugins. So saying what you would gain from one to the other is not straight forward. You gain some things and loose others.
For example Vim keeps it's undo system as a tree whereas most GUI apps keep their undo commands as a stack.
i.e. if you have series of edits and you undo 2 and then make a new change the other two edits are lost. In Vim they aren't, the tree of edits can be navigated at will.
Assuming that undo tree is a useful feature to you (it is for me) I'd have to do a good search of Pycharm plugins before I can say it's a definite advantage of Vim.
Equally you might find that Pycharm has some code aware feature that Vim can't provide via an LSP plugin or VS Code extension in which case you'd want to stay using Pycharm.
This may be a useful or a detrimental comment, but I would say if you see yourself as a developer, then Pycharm may win out. If you see yourself as a more low level coder then vim may win out.
The main advantage of vim to me is homogeneity across different platforms and languages. Oh yeah, and the next question is do you love your terminal? Are you the type of person that would browse the web with your terminal and write ToDo lists in your terminal? If not, again Pycharm may be the preferred candidate.
The main advantage of vim to me is homogeneity across different platforms and languages. Oh yeah, and the next question is do you love your terminal? Are you the type of person that would browse the web with your terminal and write ToDo lists in your terminal? If not, again Pycharm may be the preferred candidate.
flame bait
Vim is a tool like any other tool. Well, a powerful tool. Having a good editor is essential when working with text. For any task pick the right tool for the job. An expert task requires expert tools. There are many good expert tools. Pick your poison.
The article is well written, and the authors has a good point. I don't think there are that many situations where "dive in head first" is that good of an idea.. Slip in where you can find ground, and work your way out until you learn to swim. I'd never switch off my cursor keys, I don't CARE if it's supposed to be more efficient. That's how I feel right now, maybe one day, I'll feel different, but if I do, I won't recommend any new users to do the same, that's just silly.. I mean, that'd do nothing but scare them away and make their lives miserable.