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.
The reason I learned Vim in 2019 is b/c I wanted a lightweight, powerful, ubiquitous tool. I was willing to overcome the learning curve, but it took time. The most helpful advice I got was from this article https://medium.com/actualize-network/how-to-learn-vim-a-four...:
Week 1: Complete vimtutor once a day, every day
Week 2: Use Vim with minimal config, no plugins
Week 3: Use Vim with minimal plugins
Week 4: Compose Vim commands with verbs and nouns
I use vim because its got :sp/:vsp, can edit remote files over scp, :E, :earlier, and now :term, plus so many options in vimrc. I don't think I really even need tmux w/ it anymore.
Wow, I've been using vi for 30 years and I had never seen :sp/:vsp, :E, :earlier or :term (although you can do :sp with ^W s). I always feel like there's still a lot of "hidden" functionality in vim that I need to uncover one of these days.
> 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!
: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.
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.
This 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.
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.
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.
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.
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.
For what it's worth: I really don't care to tell people what editor to use. But I do think that everyone should think about spending some time with vimtutor. Not because it will turn you into a 10x developer, or because vim has the best keybindings ever, or anything like that. I've never bought it. But I do believe that it is very likely to make your life easier, even if you don't actually use vim.
Let me explain: I've been an emacs person for decades now. I was never super committed to it, though. In practice, I'll use whatever editor has the best plugin for the language I'm working in. Which means that, for the longest time, I had to try and keep track of 4 or 5 different sets of editor keyboard commands. Which is too damn much for one brain, so I found that, over time, I stopped being as efficient in any editor as I was in emacs 25 years ago.
So why vim? Because every editor worth its salt has an option to use vim keybindings. So you don't have to learn 4, 5, 6 different sets of editor commands. You can learn one, and learn it well.
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.
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.
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.
> 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.
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
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.
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
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).
> 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.
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 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).
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'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.
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.
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.
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.
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.
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
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'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.
If you're interested in vim, but hesitant about the lack of IDE bells and whistles, VSCode's vim bindings are so good - with full support for e.g. splits, macros, buffers, ... - that I've finally converted to using that over raw vim.
Most anything that VSCode can do, you can make vim do with plugins, but it is often incredibly time consuming and finnicky to get up and running, whereas with VSCode everything "just works".
All the productivity of being able to edit text in vim, alongside the conveniences of a real, modern IDE.
I'll add that all Jetbrains products (IntelliJ, PyCharm, WebStorm etc) have the IdeaVim plugin which is also great, and it also respects some vimrc configurations too.
I always loved vims movement and editing and hated it's file traversal / project management, so this is a perfect amalgamation
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.
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...
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.
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.
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.
- 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.
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'm a vim user turned JetBrains user. I still use IDEAVim inside of all of the JetBrains offerings. I go back and forth wanting to purely use vim but I can't warrant all of the config overhead. To me that's the biggest reason not to use pure vim instead of a vimulator.
The vim ecosystem reminds me of the node ecosystem. It's a choose your own adventure approach. Yes, there are wonderful and powerful tools, but it's always a shotgun of plugins to get a solution for each language you want to support. With JetBrains, I get 90% of the tooling I need for the language I'm using out of the box. The other 10% can be handled by plugins and some small configuration changes.
I'm posting this because I want to be convinced otherwise. Here are the JetBrains features that I can't live without:
- Contexts: https://www.jetbrains.com/help/idea/managing-tasks-and-context.html#work-with-context
- Re > I'm usually working with a 6 to 8 way split. Kind of like the tabs on my browser.
- VCS tooling
- Handles multiple git repos from a top level. I can commit across all repos or a single repo selectively
- File change view
- Merging view
- Per line commit selection
- Inbuilt database tooling
- Ad hoc queries and output directly next to the code you're prototyping
- Database introspection
- Symbol based refactoring
- Visual debugger
- Multiple module repo
- You can configure a language/ecosystem per each directory in your project to get the associated tooling for each directory
- Scratch files
- Local history
- This has saved my ass more than once. It's amazing how far back you can go outside of commit history with this.
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.
I don't agree. I work in cloud / ssh environments all the time. My main computer is a mac and I need to copy text to and from multiple machines and the host machine. I write C++ and other languages on all the remote machines. https://micro-editor.github.io is the only viable alternative for me as its more modern and supports all the features I would expect from this distributed environment.
While I've only given micro a cursory look, it doesn't seem to have any particularly unique features compared to Vim, and from all appearances it's far less powerful. (This isn't the knock it might seem to be; it's hard to match any editor that's been under fairly active development for 25+ years.) I'm also not sure what you meant by "this distributed environment"; if you're SSHing to cloud servers and running micro in a terminal there, that's "distributed" in exactly the same way people have been running Emacs and Vim for decades.
My main computer is also a Mac and I also need to copy text to and from multiple machines and the host machine, and while I don't write C++, I do write other languages on all the remote machines -- and BBEdit lets me do that a lot more easily, since it has menu commands for save/open over FTP/SFTP. But it's certainly not unique in that regard. (Personally I've found Vim's netrw implementation of this a bit clunky and never got Emacs's functionality for this working quite right, although "Never Got Emacs Working Quite Right" may be my epitaph).
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.
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.
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.
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).
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).
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.)
> 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
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.
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.
> 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'}
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.
> 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.
> 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.
142 comments
[ 3.7 ms ] story [ 178 ms ] threadWeek 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
The Vim author was against adding :term but their hand was forced by the success of neovim from what I understand.
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 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
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.
The busybox implementation kinda sucks at times, but I can't complain given that they've obviously focused on size.
Although, surprisingly, most command-line interfaces and command-driven apps (like redis client and psql) use emacs key bindings for command history.
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.
The issue is with HNers who have promoted it and highlighted 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.
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.
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.)
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...
I like my emacs line editing mode :D
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.
- 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.
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.
- google chrome
- sql server management studio
- jupyter notebook
- jupyter lab
- visual studio code
- ms visual studio
- dbeaver
- eclipse
- sublime text 2
- hackerank, iirc
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.
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.
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.
Editing source code, on the other hand, benefits much more from vim, because inserting text is only part of it.
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
> Sometimes, you edit text outside of Vim. These are sad times. Enter vim-anywhere!
https://github.com/cknadler/vim-anywhere
Here’s another:
https://github.com/akahuku/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.
Firefox: https://www.reddit.com/r/firefox/comments/8y0q23/vim_mode_fo...
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.
Yeah, this is weird to me. I've seen some people list it on their resume. Why should I care what editor you use?
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.
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
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 always loved vims movement and editing and hated it's file traversal / project management, so this is a perfect amalgamation
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:
Or to create/switch git branches: Or to bring up the nav bar to change or create new files (Ctrl/Cmd + N once the nav bar is visible): Or to summon git blame annotations in the current file (repeat to dismiss them): Or manipulate windows: Or summon “Refactor This” at the cursor point: You can get a list of available actions for your current environment and plugins with the :actionlist command.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...
There goes my afternoon...
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.
https://stackoverflow.com/questions/34528322/how-to-include-...
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.
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.
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.
- 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.
I can't even count the times I've accidentally written :w into a document while using an editor without vim bindings.
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:
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.
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).
Years later, I started thinking that sooner or later, a simpler, better alternative would emerge.
It's 2020, and I'm still waiting.
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.
Also, for some reason, many modern systems still only install vi by default. If you know vim, you know vi; but it is missing enough features to be annoying.
The thing I'm running into recently is that it gets very slow for large files. Unfortunately, where I work, the norm is to have files be thousands and thousands of lines long, which causes my setup which otherwise works fine to become very slow.
It's probably a plugin I'm using, but as you say, it now becomes my responsibility to figure out which one it is. Contrast this with vscode, which works fine out of the box, and already has most features built in.
You 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 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).
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.)
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.
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
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
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.
* 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 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'}
> 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.
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.
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.