Why Should You Learn Vim in 2020(pragmaticpineapple.com)
pragmaticpineapple.com
Why Should You Learn Vim in 2020
https://pragmaticpineapple.com/why-should-you-learn-vim-in-2020/
142 comments
> 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.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s...
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...
MacOS uses ctrl+a/ctrl+e EVERYWHERE (but it doesn't work well in Microsoft products, if it works at all).
I like my emacs line editing mode :D
I like my emacs line editing mode :D
This is one of my favorite things about macOS.
I love that control+a and command+a have different functions. I use control+k and control+a all the time while writing comments on websites, etc. Especially since I've been mapping caps-lock to control for more than a decade.
I love that control+a and command+a have different functions. I use control+k and control+a all the time while writing comments on websites, etc. Especially since I've been mapping caps-lock to control for more than a decade.
It also means you can use the usual cmd+c in a terminal window. That alone makes Macs my favorite console machine lol. I mean at least Linux has ctrl+shift+c too. Windows: shift+insert? REALLY?! WTF? lol. :D
> 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'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.
Both Chrome and FF have plugins to add vim key bindings - at least for navigating around the UI and the page. Which would support the argument to learn them. I guess your argument would be stronger if there were other $editor_of_choice key bindings for browser textboxes?
There are key bindings for other editors, they're called CUA :-)
I can Ctrl-C/Ctrl-X/Ctrl-V to copy/cut/paste, Ctrl-arrows to move around one word at a time, Ctrl-shift-arrows to select words, Home and End to go to the start and end of the line, etc, Ctrl-Home/Ctrl-End to move to the start and end of the text input, etc.
I can Ctrl-C/Ctrl-X/Ctrl-V to copy/cut/paste, Ctrl-arrows to move around one word at a time, Ctrl-shift-arrows to select words, Home and End to go to the start and end of the line, etc, Ctrl-Home/Ctrl-End to move to the start and end of the text input, etc.
On macOS a majority of UI text fields support readline bindings (^A, ^E, etc) which is really nice
> support readline bindings (^A, ^E, etc.)
Those are emacs bindings. Readline uses emacs bindings by default, but it can also use vi bindings.
Unless you mean that it uses readline and so configuring it (i.e. ~/.inputrc) allows you to change the keybindings of macOS UI text fields. That'd be cool if it's the case.
Those are emacs bindings. Readline uses emacs bindings by default, but it can also use vi bindings.
Unless you mean that it uses readline and so configuring it (i.e. ~/.inputrc) allows you to change the keybindings of macOS UI text fields. That'd be cool if it's the case.
I have a big issue with these bindings: there is no "right" ctrl on my MBP keyboard. If you touch type, I find ^A very cumbersome to type. I find it easier to use mac os default (cmd + arrow) which also opens variants such as option + arrow, shift + option + arrow. The only readline binding I do use is ^K (not as bad as ^A because k is on the right side of the keyboard, and there is no alternative anyway).
I read this comment 20 minutes ago and tweeted about it. I came back here to provide a link to a browser plugin for vi keybindings and found many other people had also commented with examples- only different ones.
Here’s another:
https://github.com/akahuku/wasavi
Here’s another:
https://github.com/akahuku/wasavi
I checked the comment before commenting, and turns out someone already mentioned wasavi.
Very useful tool, too bad it does not support key mapping. I'd like to `nmap gj <ESC>` or the essential `nmap j gj`, because writing on small `<textbox/>` tends to wrap the content.
Very useful tool, too bad it does not support key mapping. I'd like to `nmap gj <ESC>` or the essential `nmap j gj`, because writing on small `<textbox/>` tends to wrap the content.
> 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).
But both in this box and in google docs (and so many more places) you have access to the basic emacs C-* cursor movement and line manipulation bindings.
One should really know both vi and emacs style basic movement bindings. Both work in many places, sometimes it's one or the other.
But both in this box and in google docs (and so many more places) you have access to the basic emacs C-* cursor movement and line manipulation bindings.
One should really know both vi and emacs style basic movement bindings. Both work in many places, sometimes it's one or the other.
Here, that will let you greatly expand where you can use vim:
> Sometimes, you edit text outside of Vim. These are sad times. Enter vim-anywhere!
https://github.com/cknadler/vim-anywhere
> Sometimes, you edit text outside of Vim. These are sad times. Enter vim-anywhere!
https://github.com/cknadler/vim-anywhere
I'm working slowly on a Vim mode also that works in all text areas without kicking people into Vim: https://github.com/dbalatero/VimMode.spoon
Very interesting! I will give it a go.
Oh my god thank you so much for posting this!
> I'm typing this message in a text box in my browser and I don't have access to vim
https://github.com/GhostText/GhostText
GhostText extension for chrome/FF and listed $plugin for $editor means you can live edit a browser textarea in $editor with text sent in real time to browser.
Unfortunately, Google Suite(docs etc.) does not play nice and does not work.
Worth checking out.
Also for a more embedded vim experience: https://github.com/glacambre/firenvim
https://github.com/GhostText/GhostText
GhostText extension for chrome/FF and listed $plugin for $editor means you can live edit a browser textarea in $editor with text sent in real time to browser.
Unfortunately, Google Suite(docs etc.) does not play nice and does not work.
Worth checking out.
Also for a more embedded vim experience: https://github.com/glacambre/firenvim
I believe he meant code editors.
Examples of which I have used Vim bindings
- google chrome
- sql server management studio
- jupyter notebook
- jupyter lab
- visual studio code
- ms visual studio
- dbeaver
- eclipse
- sublime text 2
- hackerank, iirc
- google chrome
- sql server management studio
- jupyter notebook
- jupyter lab
- visual studio code
- ms visual studio
- dbeaver
- eclipse
- sublime text 2
- hackerank, iirc
For me, writing short prose like emails or internet comments doesn't really require vim keybindings. It mostly requires keyboard for what it was designed for - inserting text.
Editing source code, on the other hand, benefits much more from vim, because inserting text is only part of it.
Editing source code, on the other hand, benefits much more from vim, because inserting text is only part of it.
[deleted]
I use macos and linux and the keybindings are compatible with emacs.
For Chrome, there's wasavi: https://chrome.google.com/webstore/detail/wasavi/dgogifpkoil...
Firefox: https://www.reddit.com/r/firefox/comments/8y0q23/vim_mode_fo...
Firefox: https://www.reddit.com/r/firefox/comments/8y0q23/vim_mode_fo...
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.
- 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.
Sublime Text has a vintage mode which has vim controls, which is very nice. It does not have an advanced set of commands that perhaps other editors might have, but it has the core commands. https://www.sublimetext.com/docs/3/vintage.html
I find that the editors I use most —- TextMate and the JetBrains suite —- also have the option to use Emacs bindings. I try to maintain functional literacy with vi(m), because it tends to be more available by default, but I’ll use Emacs where possible.
A fair point, and, though I'm not personally sad about making the switch, I definitely don't want to imply that other emacs users should drop everything and switch to evil mode.
But, at the risk of branding myself a traitor, I would suggest that anyone who doesn't already have emacs shortcuts burned into their muscle memory should choose to learn the vim ones, because they're somewhat more widely supported.
(And to use doom emacs to do it.)
But, at the risk of branding myself a traitor, I would suggest that anyone who doesn't already have emacs shortcuts burned into their muscle memory should choose to learn the vim ones, because they're somewhat more widely supported.
(And to use doom emacs to do it.)
I’ve found value in knowing both. And I’ve decided that I prefer Emacs because the mode I care about most —- which I informally call “just type stuff mode” —- is the default “mode” in Emacs.
There's also https://vim-adventures.com/ , which is a fun way to learn the basics.
Agreed. I don't use vim for day-to-day use, but if I have to ssh into a server it's nice to know that I can still get by.
> every editor worth its salt has an option to use vim keybindings
Also a lot of inputs use Emacs binding or a subset of it: Bash and other shells, Cisco routers, heck, even in Slack you can Crtl-a or Crtl-k.
Also a lot of inputs use Emacs binding or a subset of it: Bash and other shells, Cisco routers, heck, even in Slack you can Crtl-a or Crtl-k.
> I really don't care to tell people what editor to use.
Yeah, this is weird to me. I've seen some people list it on their resume. Why should I care what editor you use?
Yeah, this is weird to me. I've seen some people list it on their resume. Why should I care what editor you use?
dang that's... a good point actually.
[deleted]
At that point, you can use Spacemacs.
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.
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 always loved vims movement and editing and hated it's file traversal / project management, so this is a perfect amalgamation
IdeaVim is faster and less laggy than VSCodeVim in my experience.
You can even use a custom ~/.ideavimrc and bind leader shortcuts to JetBrains actions. I rarely ever touch the mouse in IntelliJ now. It's an ultra-productive environment to have the power of IntelliJ, the convenience of vim, and Spacemacs/Doom Emacs style shortcuts.
For example, to manage projects:
I only started playing with this recently but my current config is here for those interested:
https://gist.github.com/nickcernis/bcb5cb7f55c07ed3de8287d16...
It takes a bit of searching and fiddling, but once you hide all the chrome (I even hide tabs at Editor → General → Editor Tabs → Tab Placement = None), install IdeaVim and configure shortcuts how you want them IntelliJ feels just as slick as a tricked-out Emacs/vim, but with better out-of-the-box code intelligence.
On Mac I also remap Ctrl+hjkl system-wide so that I can navigate IntelliJ popovers with vim-ish shortcuts. I use Karabiner for this with the “Vi Mode, left_control + hjkl. shift/option/command + arrow working” option on this page: https://ke-complex-modifications.pqrs.org/?q=%20PC-Style%20S...
You can even use a custom ~/.ideavimrc and bind leader shortcuts to JetBrains actions. I rarely ever touch the mouse in IntelliJ now. It's an ultra-productive environment to have the power of IntelliJ, the convenience of vim, and Spacemacs/Doom Emacs style shortcuts.
For example, to manage projects:
nnoremap <leader>po :action ManageRecentProjects<CR>
nnoremap <leader>pc :action CloseProject<CR>
nnoremap <leader>gb :action Git.Branches<CR>
nnoremap <leader>fn :action ShowNavBar<CR>
nnoremap <leader>ga :action Annotate<CR>
" Window movement.
map <leader>wv :vsplit<CR>
map <leader>ws :split<CR>
map <leader>wd <C-W>c
map <leader>wx <C-W>c
map <leader>ww <C-W>w
map <leader>wl <C-W>l
map <leader>wh <C-W>h
map <leader>wk <C-W>k
map <leader>wj <C-W>j
map <leader>wo <C-W>o
nnoremap <leader>rt :action Refactorings.QuickListPopupAction<CR>
I only started playing with this recently but my current config is here for those interested:
https://gist.github.com/nickcernis/bcb5cb7f55c07ed3de8287d16...
It takes a bit of searching and fiddling, but once you hide all the chrome (I even hide tabs at Editor → General → Editor Tabs → Tab Placement = None), install IdeaVim and configure shortcuts how you want them IntelliJ feels just as slick as a tricked-out Emacs/vim, but with better out-of-the-box code intelligence.
On Mac I also remap Ctrl+hjkl system-wide so that I can navigate IntelliJ popovers with vim-ish shortcuts. I use Karabiner for this with the “Vi Mode, left_control + hjkl. shift/option/command + arrow working” option on this page: https://ke-complex-modifications.pqrs.org/?q=%20PC-Style%20S...
Any idea if there is a way to check for presence of Ideavim in vimrc/init.vim?
I have a single config for all vim related things(vimrc) and source it for neovim as well, hence I was curious. For example,
has('nvim') checks for neovim.
Something like this for 'ideavim' would mean I can add IntelliJ related stuff inside that check.
I have a single config for all vim related things(vimrc) and source it for neovim as well, hence I was curious. For example,
has('nvim') checks for neovim.
Something like this for 'ideavim' would mean I can add IntelliJ related stuff inside that check.
I haven’t tried it but there are a couple of suggested workarounds here:
https://stackoverflow.com/questions/34528322/how-to-include-...
https://stackoverflow.com/questions/34528322/how-to-include-...
Wow, I didn't realize I could map JetBrains actions. That is awesome! Thanks for the tips!
There goes my afternoon...
There goes my afternoon...
IdeaVim has a few issues due to being thrust onto another application. E.g. Ctrl-V pastes from the clipboard instead of entering visual block mode. Also, it sometimes doesn't process input in order. E.g. pressing Esc Shift-O will sometimes type an "O" before exiting insert mode instead of creating a new line above the cursor. Also useful features that aren't basic movement tend not to work, like text reflowing with gq.
I have a hot key for opening the current file in an actual vim instance whenever I want to write multiline text or use visual block mode.
I have a hot key for opening the current file in an actual vim instance whenever I want to write multiline text or use visual block mode.
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.
VSCode's vim setup is fairly customizable, and supports features from many popular vim plugins, like vim-surround, easymotion, and many others. I'd encourage you, or anyone else who's curious to give it a shot, because it may be better than you're expecting.
That being said, I haven't been able to make the switch myself yet, even though I sort of want to. The vibe is off.
That being said, I haven't been able to make the switch myself yet, even though I sort of want to. The vibe is 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.
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.
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.
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).
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).
Unpopular opinion:
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.
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.
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.
> 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.
vi/emacs will definitely still be around in 20 years. Other editors may not be.
Visual Studio Code and IntelliJ IDEA are both open source and Eclipse has been around for 18 years. This is not a legitimate concern.
> 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.
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.
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.
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.
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.
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.
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.
A lot of Linux systems (most as far as I know but could be wrong) actually ship vim but in a very stripped down build and set up to run in vi compatibility mode by default, e.g. vim.tiny on Debian and Ubuntu. BSD systems often use nvi, which is quite close to the original vi, and can feel very weird if you are used to vim.
> blazing fast
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.
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.
If you are editing over a network connection and you normally have cursorline on, then try turning it off. That makes a big difference for me when there is network latency.
> (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).
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
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:
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.
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:
https://github.com/d33tah/dotfiles/blob/master/dotfiles/vimr...
You'll also need to run:
wget https://github.com/neovim/neovim/releases/download/nightly/nvim-linux64.tar.gz -O- | tar zxvf - -C /usr/local --strip=1
https://github.com/d33tah/dotfiles/blob/master/dotfiles/vimr...
You'll also need to run:
nvim +PlugInstall +UpdateRemotePlugins +qa
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 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.
I just use tmux so I don't lose state over ssh sessions.
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 is new with Vim 8 I believe.
The Vim author was against adding :term but their hand was forced by the success of neovim from what I understand.
The Vim author was against adding :term but their hand was forced by the success of neovim from what I understand.
Your comment would be a lot more useful if you explained what those commands do.
> Your comment would be a lot more useful if you explained what those commands do.
I think it's actually more likely to be useful for you (or anyone) to get intrigued, fire up vim, and use, say, `:help :term`. At least, that's what I'm off to do!
I think it's actually more likely to be useful for you (or anyone) to get intrigued, fire up vim, and use, say, `:help :term`. At least, that's what I'm off to do!
: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.
[0]: https://github.com/mhinz/neovim-remote
[1]: https://github.com/martanne/abduco
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
I actually run vim with a single term window within a screen session. All my window splits and tabs are handled by vim. I actually run nested vim instances within those term windows amongst other things.
In other words, screen handles persistance and the ability to reattach to an existing session. The outer vim serves as a terminal manager. The nested vim instances are used to edit code, etc.
In other words, screen handles persistance and the ability to reattach to an existing session. The outer vim serves as a terminal manager. The nested vim instances are used to edit code, etc.
> 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
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
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.
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.
As common as this argument is, I've always found for me that there's a hierarchy in "ease of use" for text selection that isn't quite as simple as "device X is always better". From quickest to slowest:
* Keyboard command that requires no counting or precision and has no easily-confused variants. In almost all editors this encompasses up, down, left, right, home, end, select or delete a line, and so on; some editors have more sophisticated ones like "select all in enclosing characters", or Vim's non-parameterized text objects ("cw" for "change word" as opposed to "dt6f" for "delete to the sixth occurrence of 'f' or maybe to the character in front of it, I always forget which").
* Mouse selection in any editor that lets you do multiple clicks to change selection object (e.g.: single click character, double click word, triple click line; on a Mac this is nearly any editor, including the text box I'm typing in right now). This isn't as precise as a correctly-executed keyboard command like "dt6f" or some Emacs equivalent, but it requires less cognitive switching: you don't have to think about the command and you don't have to do any counting. You just know you want to select from there to there. If you mess up, it rarely requires any effort to recover.
* Keyboard commands that require you to think carefully before composing them. This is where Vim, god love it, sometimes falls down hard. I know exactly what I want to select, but I have to stop and think about the "best" way to select it, and if I screw it up, I have to get back to where I was and try again -- which may require yet more thinking. I don't doubt that there are people who are just super good at this and get it right first try evey time, and those people are... well, probably not much faster than someone who gets selection right with the mouse every time.
tl;dr: Mice do not suck, and I like trackpads, dammit.
* Keyboard command that requires no counting or precision and has no easily-confused variants. In almost all editors this encompasses up, down, left, right, home, end, select or delete a line, and so on; some editors have more sophisticated ones like "select all in enclosing characters", or Vim's non-parameterized text objects ("cw" for "change word" as opposed to "dt6f" for "delete to the sixth occurrence of 'f' or maybe to the character in front of it, I always forget which").
* Mouse selection in any editor that lets you do multiple clicks to change selection object (e.g.: single click character, double click word, triple click line; on a Mac this is nearly any editor, including the text box I'm typing in right now). This isn't as precise as a correctly-executed keyboard command like "dt6f" or some Emacs equivalent, but it requires less cognitive switching: you don't have to think about the command and you don't have to do any counting. You just know you want to select from there to there. If you mess up, it rarely requires any effort to recover.
* Keyboard commands that require you to think carefully before composing them. This is where Vim, god love it, sometimes falls down hard. I know exactly what I want to select, but I have to stop and think about the "best" way to select it, and if I screw it up, I have to get back to where I was and try again -- which may require yet more thinking. I don't doubt that there are people who are just super good at this and get it right first try evey time, and those people are... well, probably not much faster than someone who gets selection right with the mouse every time.
tl;dr: Mice do not suck, and I like trackpads, dammit.
> Mouse selection in any editor that lets you do multiple clicks to change selection object (e.g.: single click character, double click word, triple click line
Keyboard does that better than mouse IMHO. Alt-arrow to skip between words, alt-shift-arrow to select word to left or right.
Use correct meta or home/end key along with shift and arrow key to select the entire line, based on your platform of choice.
I'd like to see some more intelligent selection hotkeys though. JumpingBetweenCamelCase, "everything inside the quotes" { data:'inside', the:'braces'}
Keyboard does that better than mouse IMHO. Alt-arrow to skip between words, alt-shift-arrow to select word to left or right.
Use correct meta or home/end key along with shift and arrow key to select the entire line, based on your platform of choice.
I'd like to see some more intelligent selection hotkeys though. JumpingBetweenCamelCase, "everything inside the quotes" { data:'inside', the:'braces'}
I think whether the keyboard is "better" than the mouse depends to a degree on where and what you're selecting. If I want to start the selection at or very close to where the cursor is at the moment, I'm going to use the keyboard; if it's somewhere else on the screen, though, the mouse might well be quicker. (I just experienced both of those when I wanted to change the last phrase in that last sentence, and the cursor was all the way at the bottom of this comment, then wanted to edit something just one line above. The latter case, keyboard; the former case, mouse.)
> Use correct meta or home/end key along with shift and arrow key to select the entire line, based on your platform of choice.
Ideally this is just one command, I think, like Cmd/Ctrl+L for "select current line". :)
> I'd like to see some more intelligent selection hotkeys though. JumpingBetweenCamelCase, "everything inside the quotes" { data:'inside', the:'braces'}
The only editor that I've found that does both of those out of the box is BBEdit for the Mac, which uses Ctrl+left/right and Opt+left/right to navigate and select by word but Ctrl stops for camelCase and underscore breaks while Opt doesn't. And Cmd+B, "Balance," selects text between enclosing characters in the current scope: brackets, parentheses, quote marks, etc. I'm not sure why equivalents to these aren't more common in other editors.
> Use correct meta or home/end key along with shift and arrow key to select the entire line, based on your platform of choice.
Ideally this is just one command, I think, like Cmd/Ctrl+L for "select current line". :)
> I'd like to see some more intelligent selection hotkeys though. JumpingBetweenCamelCase, "everything inside the quotes" { data:'inside', the:'braces'}
The only editor that I've found that does both of those out of the box is BBEdit for the Mac, which uses Ctrl+left/right and Opt+left/right to navigate and select by word but Ctrl stops for camelCase and underscore breaks while Opt doesn't. And Cmd+B, "Balance," selects text between enclosing characters in the current scope: brackets, parentheses, quote marks, etc. I'm not sure why equivalents to these aren't more common in other editors.
> Ideally this is just one command, I think, like Cmd/Ctrl+L for "select current line". :)
I find it easier to, instead of remember another command, remember "jump to start of line, select entire line."
Mentally composable and it works in all text input boxes across the entire system. (MacOS, cmd-l selects current line in VS-Code, jumps to URL bar in Chrome.)
IMHO the problem is getting stuff to be system wide. Per editor hotkeys, or even worse. hotkeys added by plugins, cause dissonance when I sit down at someone else's computer, or just switch apps.
I find it easier to, instead of remember another command, remember "jump to start of line, select entire line."
Mentally composable and it works in all text input boxes across the entire system. (MacOS, cmd-l selects current line in VS-Code, jumps to URL bar in Chrome.)
IMHO the problem is getting stuff to be system wide. Per editor hotkeys, or even worse. hotkeys added by plugins, cause dissonance when I sit down at someone else's computer, or just switch apps.
> 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.
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.
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.
[0]: https://neovim.io/
[1]: https://github.com/asvetliakov/vscode-neovim
[2]: https://github.com/lunixbochs/actualvim
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
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.
Does vscode-neovim work around this somehow?
Does vscode-neovim work around this somehow?
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.
Could you expand on your opinion? "More modern" isn't a very convincing argument.
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).
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.)
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.)
There are several within the vast expanse of Emacs extensions:
https://github.com/mrkkrp/modalka
https://github.com/fgeller/fingers.el
https://github.com/jyp/boon
I believe I've seen at least one standalone editor focused on this, too, but I don't recall where.
https://github.com/mrkkrp/modalka
https://github.com/fgeller/fingers.el
https://github.com/jyp/boon
I believe I've seen at least one standalone editor focused on this, too, but I don't recall where.
Could it have been http://kakoune.org/why-kakoune/why-kakoune.html
Yup, Kakoune was it.
Thanks!
Edit: And, as had to be the case, someone has made a simple simulation of Kakoune for Emacs: https://github.com/jmorag/kakoune.el
Thanks!
Edit: And, as had to be the case, someone has made a simple simulation of Kakoune for Emacs: https://github.com/jmorag/kakoune.el
I learned vim properly in 1999. I was a power user back then.
Years later, I started thinking that sooner or later, a simpler, better alternative would emerge.
It's 2020, and I'm still waiting.
Years later, I started thinking that sooner or later, a simpler, better alternative would emerge.
It's 2020, and I'm still waiting.
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.
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.
Try spacemacs and lsp. Or just vanilla vim and lsp. Should work for most languages just as well as a real IDE.
I second using LSP servers. It's an absolute treat having an editor which is completely independent from the backend intellisense, which I can add my own LSP servers for however I choose.
I highly recommend https://github.com/neoclide/coc.nvim for IDE if you can use neovim. It is so far the best autocomplete tool for neovim.
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.
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.
vim
- 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.
- 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.
> 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.
I can't even count the times I've accidentally written :w into a document while using an editor without vim bindings.
I can't even count the times I've accidentally written :w into a document while using an editor without vim bindings.
I've been an nvi user for around 20 year, vim ain't for me.
Almost every reason given in the comments in favor of vim is not mutually exclusive to vim nor mutually exclusive with other features in other editors. It's easy to find vim alternatives, including GUI applications, with these supposed great features - and more.
The most significant, real benefit is the ubiquity, and the ubiquity is a function of tradition, vim's size, and its portability. This leads to its use because its 'the only option, not because 'its the best (or even good) option'. There's no arguing against the benefits of the ubiquity; its on almost every device that runs linux or unix like OS.
What really separates vim from the real day-to-day competition is the abysmal usability. From the complete lack of visibility and discoverability to the numerous modes, vim is a hall-of-shame when it comes to UX and UI. The original post even points to this stack overflow question with 3k upvotes and a top answer of 5k upvotes asking simply 'how do I quit vim': https://stackoverflow.com/questions/11828270/how-do-i-exit-t...
I don't think it's fair to ask every user to read the man pages, read a book, take a class, or go through a tutorial on how to use vim. If most users can figure out notepad.exe or TextEdit.app without reading a manual or taking a class, I think it's fair to say vim loses the usability battle, regardless of how powerful of a text editor it is.
I find most evangelists of tools have jumped from some feature anemic tool (notepad.exe or notepad++) to a more powerful tool (like notepad++ or visual studio, respectively) and decided "theres no way anything is better" then plug their ears to hearing about better tools. Nothing could possibly beat the amazing tool they use now!
JetBrains tools are less ubiquitous than vim, and sure take up more disk space. But the usability and power, as far as I can tell as I am no vim expert, far exceed that of vim. If I'm going to pick a daily-use tool, it's not going to be the one so small it fits in the tiny memory of my router, I'm going to pick the tool that with the most utility.
The original article should simply say "In many cases, vim and emacs are your only two options. When you are forced into that corner, you better know at least one of those two tools. You should learn vim because it's the (just barely) easier to use of the two ubiquitous editors."
The most significant, real benefit is the ubiquity, and the ubiquity is a function of tradition, vim's size, and its portability. This leads to its use because its 'the only option, not because 'its the best (or even good) option'. There's no arguing against the benefits of the ubiquity; its on almost every device that runs linux or unix like OS.
What really separates vim from the real day-to-day competition is the abysmal usability. From the complete lack of visibility and discoverability to the numerous modes, vim is a hall-of-shame when it comes to UX and UI. The original post even points to this stack overflow question with 3k upvotes and a top answer of 5k upvotes asking simply 'how do I quit vim': https://stackoverflow.com/questions/11828270/how-do-i-exit-t...
I don't think it's fair to ask every user to read the man pages, read a book, take a class, or go through a tutorial on how to use vim. If most users can figure out notepad.exe or TextEdit.app without reading a manual or taking a class, I think it's fair to say vim loses the usability battle, regardless of how powerful of a text editor it is.
I find most evangelists of tools have jumped from some feature anemic tool (notepad.exe or notepad++) to a more powerful tool (like notepad++ or visual studio, respectively) and decided "theres no way anything is better" then plug their ears to hearing about better tools. Nothing could possibly beat the amazing tool they use now!
JetBrains tools are less ubiquitous than vim, and sure take up more disk space. But the usability and power, as far as I can tell as I am no vim expert, far exceed that of vim. If I'm going to pick a daily-use tool, it's not going to be the one so small it fits in the tiny memory of my router, I'm going to pick the tool that with the most utility.
The original article should simply say "In many cases, vim and emacs are your only two options. When you are forced into that corner, you better know at least one of those two tools. You should learn vim because it's the (just barely) easier to use of the two ubiquitous editors."
I think if you never bring up a barebones Linux (e.g. embedded system or some old HW) you might not really need it.
But being able to connect via serial port to some crappy stripped down Linux and knowing vi is there is a good feeling and it asks nothing of you in return.
But being able to connect via serial port to some crappy stripped down Linux and knowing vi is there is a good feeling and it asks nothing of you in return.
[deleted]
I'm been an Emacs+Evil user for many years, but I would like to switch to Vim-- mainly because I use Windows 10 most of the time now and Emacs can have some input latency. But I'm old now and can't really imagine life without my init.el.
You should learn vim if you want to deal with systems. You can learn vim or not if you don't.
lookback: vi, sh and unix have become your vim, bash and linux systems of today. Now, while they have forward compatibility, of sorts, vi and sh, the same cannot be said in reverse, as a rule. Modern bash folks have bent bourne shell syntax into foreign looking contortions where bourne shell syntax is a) performant and conformant, b)a lot simpler when simpler is better and c) is why bash maintains posix.
I agree, learn basic vim. And bash. But not really to program with. It's more of a burden than not for a million languages and formats.
lookback: vi, sh and unix have become your vim, bash and linux systems of today. Now, while they have forward compatibility, of sorts, vi and sh, the same cannot be said in reverse, as a rule. Modern bash folks have bent bourne shell syntax into foreign looking contortions where bourne shell syntax is a) performant and conformant, b)a lot simpler when simpler is better and c) is why bash maintains posix.
I agree, learn basic vim. And bash. But not really to program with. It's more of a burden than not for a million languages and formats.
One useful configuration was changing the command mode key to a single letter. This way you did not have to switch back and forth between escape. Additionally, for people who have hyperhydrosis, which drastically hinders laptop touchpad usage, vim is really useful for navigation. As for vim itself, it is perhaps more effective to use a modern text editor rather than Vim as it is was a bit of a hassle to get it set up. Vim is very useful, and its good to see more encouragement for it in modern software development.
[deleted]
It ain't that difficult. Back in the late 1980s/early 1990s, I worked for a training company teaching C and C++. This was done on Unix boxes and our clients were mostly VAX VMS and IBM people. The editor we used to write code was vi (not vim). The clients had no prior experience of it, but by the end of day one of the course they could write programs using it - not without a lot of complaining, it must be admitted. Perhaps people were smarter back then?
I use it because vi is everywhere.
The busybox implementation kinda sucks at times, but I can't complain given that they've obviously focused on size.
The busybox implementation kinda sucks at times, but I can't complain given that they've obviously focused on size.
> vi is everywhere.
Although, surprisingly, most command-line interfaces and command-driven apps (like redis client and psql) use emacs key bindings for command history.
Although, surprisingly, most command-line interfaces and command-driven apps (like redis client and psql) use emacs key bindings for command history.
Most command-line interfaces use the readline library. To switch them to vi bindings put the following in ~/.inputrc:
set editing-mode viThis isn't a deliberate choice though on their part, is it? Isn't it just a consequence of everyone depending on readline and readline using emacs-style key bindings?
Some Emacs-style bindings, like ^W (erase word) and ^U (erase line), are baked into the UNIX tty discipline -- basic implementations of these bindings exist within the kernel.
Every machine I’ve ever ssh’d into has nano. Maybe that’s a new thing (most of my DevOps work has been in the past 4-5 years) but nano feels great for the kind of work I do when I ssh into something. If I need to change a config file here or a script there, nano can do it. If I need to write a whole new complicated script, I’m gonna do it on my local computer (in WSL or my Linux partition) using VS Code and deploy it to the server so it doesn’t get wiped by accident when I terminate a VM.
If you work with embedded linux, nano is almost never there.
vim/vi is to linux embedded dev what a nail gun is to roofing or a Henckel knife is too cooking. Don't show at work without it.
I find that most passionate vim advocates have spent a lot of time learning, using, twiddling vim and the investment has paid off and now life is great. Is that a point for vim or his persistence? I'm unpersuaded that I should learn vim instead of $EDITOR, I just happened on vim first. Speaking as an inveterate vim user.
For anyone who has been inspired to try vi/vim:
To exit vi or vim, press Esc then type ":q" (without quotes) and hit enter.
If it warns you about not saving, try ":wq" to save and quit or ":q!" to quit without saving.
If this is in the article video I apologize, but I did check and it's not in the article text.
To exit vi or vim, press Esc then type ":q" (without quotes) and hit enter.
If it warns you about not saving, try ":wq" to save and quit or ":q!" to quit without saving.
If this is in the article video I apologize, but I did check and it's not in the article text.
[deleted]
That's also the sequence that persuaded me that vim isn't for me. Can't even close the editor without memorizing some arcane keystroke sequence? Hard pass
I get that it's efficient once mastered but I just can't push that kind of thing to the top of my to-do list. I'll spend my time learning French or something
I get that it's efficient once mastered but I just can't push that kind of thing to the top of my to-do list. I'll spend my time learning French or something
This vimmer is always inclined to laugh at tutorials for how to exit vim … but then I remind myself that I still have to Google how to quit emacs whenever I stumble into it.
I use vim because it's guaranteed to be installed. The version installed at work is from 2004 but still.
EX mode
How to get there? Press Q in normal mode.
What is it about? To punish you for trying to type while still in normal mode, or for having fat fingers. An opportunity to type "visual" to go to Normal mode.
How to get there? Press Q in normal mode.
What is it about? To punish you for trying to type while still in normal mode, or for having fat fingers. An opportunity to type "visual" to go to Normal mode.
Larry Tesler would disagree.
https://en.wikipedia.org/wiki/Larry_Tesler
https://en.wikipedia.org/wiki/Larry_Tesler
There are so many of these articles, why write another one?
Because they're popular...
They're fluff. Somewhat easy to write and generally find an audience in both the users and the wannabes.
They will write articles about how to use Vi/Vim long after I'm dead :-)
They're one of the social discussions that hackers have, just like football fans discuss about Pele vs Maradona (or these days Messi vs Cristiano Ronaldo), boxing fans argue about Muhammad Ali vs Mike Tyson, etc.
They're fluff. Somewhat easy to write and generally find an audience in both the users and the wannabes.
They will write articles about how to use Vi/Vim long after I'm dead :-)
They're one of the social discussions that hackers have, just like football fans discuss about Pele vs Maradona (or these days Messi vs Cristiano Ronaldo), boxing fans argue about Muhammad Ali vs Mike Tyson, etc.
Content marketing. You write articles with the aim of getting people to sign up for your newsletter.
If the article is worthless the issue isn't with the author who has written it and posted it.
The issue is with HNers who have promoted it and highlighted it.
The issue is with HNers who have promoted it and highlighted it.
I didn't submit this, but it makes me wonder if emacs and vim will go the way of the dinosaur without new hackers seeing articles like this. The internet (and our industry) has a short memory, so if we're not seeing occasional articles evangelizing these technologies then they're actively losing mind-share, which would be sad.
Oh for a good (stress good) orgmode for vi(m)
I moved from Vim to Emacs and definitely prefer it as a minimalist editor. That said, I usually end up working w/ VS Code or Intellij
Oh look, yet another Vim nerdgasm
Learn Vim in 2020... because 2020 just can't get any worse.
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.