A Website for Learning Vim(vim.is)
vim.is
A Website for Learning Vim
https://vim.is/#exercise
123 comments
Us the original instead: https://www.vim.so/. This is just a clone of an indie hackers product.
Always felt the best way to learn vim is to just use it.
I'm a beginner to intermediate level vim user (well, vim bindings user), and while this is true, you don't know what you don't know.
The question is: do you need to know?
I handily accept that I don't know a big part of vim. At the same time I use it daily and went as far as developing vim script to automate stuff that are repetitive to me.
Vim bindings are quite easy to pick up and fairly straightforward though, but that should just take a cheat sheet and some usage.
I handily accept that I don't know a big part of vim. At the same time I use it daily and went as far as developing vim script to automate stuff that are repetitive to me.
Vim bindings are quite easy to pick up and fairly straightforward though, but that should just take a cheat sheet and some usage.
Let's say I want to go to the end of a word. I can press L some number of times until the cursor goes to the end of the word, or I can press E once. If I just "use" vim, how will I discover that? (Contrived example of course)
Another super simple example is replacing a word. Let's say I know how to delete, how to word, and how to enter insert mode. Putting that together I get dwi - except using cw achieves the same thing.
Another super simple example is replacing a word. Let's say I know how to delete, how to word, and how to enter insert mode. Putting that together I get dwi - except using cw achieves the same thing.
That's where the cheat sheet come in, all of these basic concepts are condensed and is literally everywhere.
Now, almost every single key has it's use and I likely only have muscle memory on about 20 keys, when it gets to the vim command line, I know even less. But I'm not quite worried about it.
Now, almost every single key has it's use and I likely only have muscle memory on about 20 keys, when it gets to the vim command line, I know even less. But I'm not quite worried about it.
Spending a week on an island in the middle of the Pacific with very little internet really got me to appreciate :help.
But I think it's important to gradually use vim. If you're new to vim leave your IDE installed.
true, but mixing things up can sometimes be fun too
www.colonwqbang.com is still available.
Doesn't look like it is, I just tried to go there without success.
OP may have been referring to the domain name.
This looks verrryy similar to https://www.vim.so
The pricing is even the same :)
What? They want one to pay for learning vi/vim? I think, it should be the other way around, that is rewarding ppl for choosing to learn it and keep the knowledge active in their memory.
Especially true now, with so many reasons not to use it AND the sufficience of :help and vimtutor for the rest of the reasons.
I find that the best teacher in this case is a necessity. Find yourself on a basic command line with no nano or the likes, just good old vi, not even vim. Then go on with that important mission you're on! Traumatizing? Yes, but a chance at adaptation too.
Especially true now, with so many reasons not to use it AND the sufficience of :help and vimtutor for the rest of the reasons.
I find that the best teacher in this case is a necessity. Find yourself on a basic command line with no nano or the likes, just good old vi, not even vim. Then go on with that important mission you're on! Traumatizing? Yes, but a chance at adaptation too.
What's wrong with the built-in `vimtutor`?
nothing is wrong.
Some people prefer guided tutorials that give you direct feedback (e.g. correct / incorrect).
Vimtutor is perfect for self-guided and self-motivated
Some people prefer guided tutorials that give you direct feedback (e.g. correct / incorrect).
Vimtutor is perfect for self-guided and self-motivated
https://vim-adventures.com/ is the place to learn vim ... and the vimtutor
I knew vim well before I read this advice, so didn't need it myself, but think it's worthy: Go through vimtutor, then use the native vim for you platform that also has a GUI, so when you get frustrated you can 'fall back' to using menus. Over time replace your menu-fallback stuff with "hand on the keyboard" techniques. It was soooo frustrating in the early going with vim. Very distracting from what I was trying to do. (Presumably true for most of us.)
I learned Vim by watching some videos of a guy talking VERY enthusiastically about Vim. I can't find them anymore though. Was just some programmer explaining Vim in a series of videos. Probably almost 10 years ago. Anyone know what I'm talking about?
EDIT Found it! This guy is brilliant. http://derekwyatt.org/vim/tutorials/index.html
EDIT Found it! This guy is brilliant. http://derekwyatt.org/vim/tutorials/index.html
Thanks--these look great!
Edit: There are a lot of great Vim videos on thoughtbot's YouTube channel, too.
Edit: There are a lot of great Vim videos on thoughtbot's YouTube channel, too.
Both this website and vimtutor teach basic commands (finger mechanics) but some learn more effectively if they have some of the philosophy and logic of why vi/vim works the way it does. For example, this popular Stackoverflow answer explains vim's concepts of "verb + noun" commands: https://stackoverflow.com/questions/1218390/what-is-your-mos...
Also, a lot of beginners are perplexed why vi uses "hjkl" keys for cursor movement. It's because the 1976 ADM-3A terminal didn't have any dedicated arrow keys like the 1986 IBM PC 101-key layout: https://catonmat.net/why-vim-uses-hjkl-as-arrow-keys
Without background info like that, learning vi can seem like memorizing random incoherent trivia.
Also, a lot of beginners are perplexed why vi uses "hjkl" keys for cursor movement. It's because the 1976 ADM-3A terminal didn't have any dedicated arrow keys like the 1986 IBM PC 101-key layout: https://catonmat.net/why-vim-uses-hjkl-as-arrow-keys
Without background info like that, learning vi can seem like memorizing random incoherent trivia.
On the hjkl thing, I think it's also good to explain why it was a good idea that the ADM-3A used hjkl, and that's because it allows directional navigation (an extremely common operation) without moving your fingers away from their "home row" position.
So vi/vim use those keys not /only/ because some old terminal, but because some old terminal used those keys /and/ there was a benefit to it.
So vi/vim use those keys not /only/ because some old terminal, but because some old terminal used those keys /and/ there was a benefit to it.
Thank you for pointing this out!
Having my fingers leave home row as little as possible is vastly superior to reaching for arrow keys and having to reposition my fingers on home row.
With vi that made immediate sense to me. Switching to HHKB layout made even more sense, because I now can reach both CTRL and backspace easily without lifting my fingers from home row.
I did change my keymap even further, so that arrow keys are mapped to fn+hjkl. This way, I can navigate everything just with hjkl (:
Having my fingers leave home row as little as possible is vastly superior to reaching for arrow keys and having to reposition my fingers on home row.
With vi that made immediate sense to me. Switching to HHKB layout made even more sense, because I now can reach both CTRL and backspace easily without lifting my fingers from home row.
I did change my keymap even further, so that arrow keys are mapped to fn+hjkl. This way, I can navigate everything just with hjkl (:
>I did change my keymap even further, so that arrow keys are mapped to fn+hjkl. This way, I can navigate everything just with hjkl (:
Yeah once you get used to vim way of working with text you can essentially never go back.
Yeah once you get used to vim way of working with text you can essentially never go back.
> Also, a lot of beginners are perplexed why vi uses "hjkl" keys for cursor movement.
I really don't understand why people get hung up on this. Vim supports arrow keys. hjkl are convenient alternatives but if you're at the point of not being comfortable switching between normal and insert mode just use the arrow keys. Insisting othereise is insisting you learn everything at once, which is demotivating and unnecessary.
Arrow keys are more versatile too. They do the behavior you expect in pretty much any mode.
I really don't understand why people get hung up on this. Vim supports arrow keys. hjkl are convenient alternatives but if you're at the point of not being comfortable switching between normal and insert mode just use the arrow keys. Insisting othereise is insisting you learn everything at once, which is demotivating and unnecessary.
Arrow keys are more versatile too. They do the behavior you expect in pretty much any mode.
I knew a vim-evangelist developer once who added bindings to his .vimrc file so that, if you pressed an arrow key in insert mode, it would insert the appropriate arrow symbol. I think this was meant to train the user _not_ to use the arrow keys to navigate around, but rather to switch to normal mode and use hjkl or other movement commands.
While I don't approve of this on a practical level, I have to admit that I find the logic of the joke hilarious. You were in insert mode, and you pressed the arrow key, so it ... inserted an arrow.
While I don't approve of this on a practical level, I have to admit that I find the logic of the joke hilarious. You were in insert mode, and you pressed the arrow key, so it ... inserted an arrow.
>I really don't understand why people get hung up on this. Vim supports arrow keys. hjkl are convenient alternatives [...]
Maybe because tutorials like vimtutor and this thread's website immediately blast hjkl finger exercises at the brand new user with no context whatsoever. The student is now wondering why they are pressing a seemingly arbitrary and random alphabet key just to move a cursor around.
E.g. vimtutor 1st screen:
Also, in my case, I learned classic vi (not vim) on DEC UNIX and the arrow keys did not work. Instead, the arrow keys inserted funny control characters depending the terminal emulation. So people used to be forced into using hjkl.
Maybe because tutorials like vimtutor and this thread's website immediately blast hjkl finger exercises at the brand new user with no context whatsoever. The student is now wondering why they are pressing a seemingly arbitrary and random alphabet key just to move a cursor around.
E.g. vimtutor 1st screen:
Now, make sure that your Caps-Lock key is NOT depressed and press
the j key enough times to move the cursor so that lesson 1.1
completely fills the screen.
You can use the h and l keys to move the cursor.
Also, in my case, I learned classic vi (not vim) on DEC UNIX and the arrow keys did not work. Instead, the arrow keys inserted funny control characters depending the terminal emulation. So people used to be forced into using hjkl.
Yes, and because the control characters sometimes included the Esc key, this could even take you out of insert mode willy-nilly, and maybe delete / change some of your text, suddenly.
vim seems like very compusive tool at first but as you keep using this is seems like very productive. thats how it was for me
Reminder: VSCode, Visual Studio, IntelliJ, and Notepad++ all individually have a higher usage share among professional programmers[0]. Vim is similar to Android Studio. But you'd never know that such un-sexy tools are actually super popular reading technical sites.
And before the "but it is already on your server!" You know what else is installed on almost every *NIX server? Nano. A text editor that needs no deep introduction to be productive or that you have to reconfigure basic keybinds like the arrow keys "because it could break a system not used since the 1970s!"
I know Vim well, I've used Vim a lot, still don't understand the strange obsession people have with getting others into it. You want some professional advice? Don't learn Vim, learn Nano, and use the time you saved to learn VSCode better.
[0] https://insights.stackoverflow.com/survey/2021#most-popular-...
And before the "but it is already on your server!" You know what else is installed on almost every *NIX server? Nano. A text editor that needs no deep introduction to be productive or that you have to reconfigure basic keybinds like the arrow keys "because it could break a system not used since the 1970s!"
I know Vim well, I've used Vim a lot, still don't understand the strange obsession people have with getting others into it. You want some professional advice? Don't learn Vim, learn Nano, and use the time you saved to learn VSCode better.
[0] https://insights.stackoverflow.com/survey/2021#most-popular-...
With the implication that you "save a lot of time" by learning another editor (nano) you are confusing skill ceiling with skill floor. If you want to compare those editors, compare them at the learning level you are presenting them.
The other editors do not involve any learning if you don't learn anything about them, Vim involves a lot of learning if you learn most of its features. However to use Vim in the way you present the other editors, you don't have to learn much at all, arrow keys work, the gui version has window menus for most options.
Want to use Vim without the learning? i to insert, ESC to go back from insertion mode, arrow keys to navigate, there you are, you are basically using Vim at the level that you want people to use other editors.
If I want much more than that I'll have to learn the features and keybindings of the other editors too. Last time I checked the knowledge of how to search, split panes, switch buffers, search and replace etc. wasn't magically inserted into my brain as soon as I open my copy of VSCode or Nano.
> you have to reconfigure basic keybinds like the arrow keys
Since when do arrow keys not work in Vim by default?
Learning all of Vims features vs. learning only the minimum in other editors is not a fair comparison.
The other editors do not involve any learning if you don't learn anything about them, Vim involves a lot of learning if you learn most of its features. However to use Vim in the way you present the other editors, you don't have to learn much at all, arrow keys work, the gui version has window menus for most options.
Want to use Vim without the learning? i to insert, ESC to go back from insertion mode, arrow keys to navigate, there you are, you are basically using Vim at the level that you want people to use other editors.
If I want much more than that I'll have to learn the features and keybindings of the other editors too. Last time I checked the knowledge of how to search, split panes, switch buffers, search and replace etc. wasn't magically inserted into my brain as soon as I open my copy of VSCode or Nano.
> you have to reconfigure basic keybinds like the arrow keys
Since when do arrow keys not work in Vim by default?
Learning all of Vims features vs. learning only the minimum in other editors is not a fair comparison.
Other editors don't require nearly the same effort to learn because features are (typically) easily discoverable via the menu bar, or use standard shortcuts. I've never used VSCode in my life, but I bet you a dollar that control-C copies, control-V pastes, and control-F brings up a search dialogue. I also would bet that if I want to split a pane, I can figure out how to do that my mousing around the menu in under ~30 seconds.
Whereas, trying to do pane-like things in vim requires Googling (more efficient in my experience than trying to use the built-in manual) and then reading some stackexchange answer that devolves into a philosophical discussion about the merits of buffers versus tabs.
Whereas, trying to do pane-like things in vim requires Googling (more efficient in my experience than trying to use the built-in manual) and then reading some stackexchange answer that devolves into a philosophical discussion about the merits of buffers versus tabs.
I think that the journey that you went through (philosophical discussion about...) is more important than just going on with your life which is made easy in VSCode. This eventually gives rise to a community. Like I can assume that hacker news readers can (or figure out how to) exit vim without using any search engine.
I, uh... should preface this by saying that vim is my main editor, and I always install a vim plugin if possible when using a different one. It's great, it makes me faster, etc. etc.
Alright, that aside, when all is said and done I think a lot of people just want to edit their file. Parent comment about having to go to Google to do simple things makes a good point, and the response that "actually, I think having to read a bunch of troglodytes arguing with each other on Stack Overflow is an important part of the experience" is the kind of thing that makes it hard for everyone else to take vim fanatics seriously.
Alright, that aside, when all is said and done I think a lot of people just want to edit their file. Parent comment about having to go to Google to do simple things makes a good point, and the response that "actually, I think having to read a bunch of troglodytes arguing with each other on Stack Overflow is an important part of the experience" is the kind of thing that makes it hard for everyone else to take vim fanatics seriously.
The problem with Vim only development we don't have the OS support to use only the keyboard.
Soon or later you have to reach for the mouse to scroll through the browser, or change/rearrange windows, even with all the fancy Vim plug-ins.
Soon or later you have to reach for the mouse to scroll through the browser, or change/rearrange windows, even with all the fancy Vim plug-ins.
I'm not sure why that's a problem for using vim, as if the only reason people use vim is to avoid using the mouse.
> Reminder: VSCode, Visual Studio, IntelliJ, and Notepad++ all individually have a higher usage share among professional programmers[0].
20 years ago, this list would have had a bunch of different names on it.
20 years from now, it will be different names still.
Meanwhile, vim will still be there, and my knowledge in it built 20 years ago will be serving me still 20 years from now.
20 years ago, this list would have had a bunch of different names on it.
20 years from now, it will be different names still.
Meanwhile, vim will still be there, and my knowledge in it built 20 years ago will be serving me still 20 years from now.
Knowledge between modern editors and IDEs is generally highly transferrable. You don’t magically forget how to copy / paste when going from Pycharm -> VScode.
> I know Vim well, I've used Vim a lot, still don't understand the strange obsession people have with getting others into it.
The reason someone might advocate for its adoption can lead to greater availability (this is why there's a vim mode in pretty much every other text editor). Or they think it's a better way to edit text and want others to experience it. I would love if I could edit text in everything as I do in vim because editing text in the more "intuitive" way is slow and clunky and frustrating.
I think what's more peculiar is the strange obsession people have with dumping on vim or on the people who are advocating for its use. It reads as petty and insecure.
The reason someone might advocate for its adoption can lead to greater availability (this is why there's a vim mode in pretty much every other text editor). Or they think it's a better way to edit text and want others to experience it. I would love if I could edit text in everything as I do in vim because editing text in the more "intuitive" way is slow and clunky and frustrating.
I think what's more peculiar is the strange obsession people have with dumping on vim or on the people who are advocating for its use. It reads as petty and insecure.
Excuse me, my obsession with dumping on vim is not strange! It is well justified by the fact that, due to several positive comments on HN, I spent many, many hours trying to learn and use vim only to realize that it was fundamentally slower, and imposed a higher cognitive burden, than the editing tools I was previously using. I only want to save other people the same trouble.
I realize my experience is n=1, my editing needs might not by typical or generalizable, etc. But I do think it is important to push back a bit on vim boosterism.
I realize my experience is n=1, my editing needs might not by typical or generalizable, etc. But I do think it is important to push back a bit on vim boosterism.
I'll bump you up to n=2!
I learned vim to, say, like, a low-moderate-ish proficiency? Basically forced myself to use it everywhere at work and home. After a few weeks of this... I went back to just vanilla IDEs/Editors.
For me, it was just a mix of not liking some stuff being handled in vim bindings and some stuff being handled by the IDE's bindings. I'm sure there's a bunch've plugins or customizations that'd smooth it over, but... vim also made me realize, I'm a pretty meat and potatoes text editing kinda guy. I like to shift lines, expand selections in a context aware way, and copy/paste. When I split panes, I do it with the mouse like a cave man. So the bulk of vims power was either lost on me, or felt like it got in the way of my minimal needs.
Also, I pretty much never ssh onto an individual machine to edit anything substantial these days, so... the selling point of having some bedrock transferable "everywhere" skill is kinda moot.
I learned vim to, say, like, a low-moderate-ish proficiency? Basically forced myself to use it everywhere at work and home. After a few weeks of this... I went back to just vanilla IDEs/Editors.
For me, it was just a mix of not liking some stuff being handled in vim bindings and some stuff being handled by the IDE's bindings. I'm sure there's a bunch've plugins or customizations that'd smooth it over, but... vim also made me realize, I'm a pretty meat and potatoes text editing kinda guy. I like to shift lines, expand selections in a context aware way, and copy/paste. When I split panes, I do it with the mouse like a cave man. So the bulk of vims power was either lost on me, or felt like it got in the way of my minimal needs.
Also, I pretty much never ssh onto an individual machine to edit anything substantial these days, so... the selling point of having some bedrock transferable "everywhere" skill is kinda moot.
> I spent many, many hours trying to learn and use vim only to realize that it was fundamentally slower
Your lack of proficiency in vim does not mean it is fundamentally slower.
Your lack of proficiency in vim does not mean it is fundamentally slower.
> I realize my experience is n=1, my editing needs might not by typical or generalizable, etc.
> I only want to save other people the same trouble.
Pick one!
> I only want to save other people the same trouble.
Pick one!
I don't think there's anything wrong with saying some people may have needs similar to mine, and some may not. I've tried to spell out in other comments what those needs and experiences were so that people can make an informed decision.
> don't think there's anything wrong with saying some people may have needs similar to mine, and some may not.
To be frank, it's annoying to go to a HN comments page and find the inevitable "popular tool x sucks because I didn't like it" comments. It seems like they're everywhere, on every link about every tool or product on HN. It's a buzzkill. Of course not everybody is going to like Vim. This link isn't trying to convince anybody of anything, it's just there for anybody trying to learn.
To be frank, it's annoying to go to a HN comments page and find the inevitable "popular tool x sucks because I didn't like it" comments. It seems like they're everywhere, on every link about every tool or product on HN. It's a buzzkill. Of course not everybody is going to like Vim. This link isn't trying to convince anybody of anything, it's just there for anybody trying to learn.
After just a week in Vim, being required to move my hands of the home row feels like a significant, possibly even disturbing undertaking.
For me, and I assume many others, vim is fun. It sort of gamifies text editing. There's always new things to learn, and executing advance keystrokes is satisfying. Once you know them, moving to other IDE's is a pleasure because they all offer a vim mode (with varying levels of compatibility). Personally I use vim / emacs + evil / jetbrains depending on the task.
But if you don't care about that aspect, I agree with you, just stick with the boring thing that works. I don't think vim really saves me much time in the long run, but it sure makes my daily tasks more fun.
But if you don't care about that aspect, I agree with you, just stick with the boring thing that works. I don't think vim really saves me much time in the long run, but it sure makes my daily tasks more fun.
VSCode, Visual Studio, and IntelliJ all support vim bindings.
For me, the most useful part of vim is that once you learn how to use it, you can switch text editors without needing to relearn most of their shortcuts.
For me, the most useful part of vim is that once you learn how to use it, you can switch text editors without needing to relearn most of their shortcuts.
Every time I try an IDE (admittedly not very often) I end up frustrated that its Vim binding implementation is incomplete. It feels even worse than using its default bindings because I start to feel confident and then suddenly it doesn't work as expected and I feel cheated :-) I guess after a while you learn what to expect from the Vim implementation of your IDE of choice but I haven't yet had the patience to reach that stage.
For this exact reason, I keep going back to vim and doing whatever I was doing on vim instead.
Jetbrains editors have by far the best implementation, but it's not there and I don't think it's possible, due to inherent lag
Jetbrains editors have by far the best implementation, but it's not there and I don't think it's possible, due to inherent lag
I think XCode's new vim mode is the only time I've found it truly jarring how incomplete the mode was, but it's certainly better that it's there than not.
all support vim bindings
Last time I tried za and it didn’t work. These extensions stop right at the impedance raising point, it’s something you should know beforehand.
Last time I tried za and it didn’t work. These extensions stop right at the impedance raising point, it’s something you should know beforehand.
I have used all of those editors and a dozen more over the years, but Vim is just the best by a large margin (IMO). The neovim plugin ecosystem includes everything I could possibly want from those IDEs, for every language, and most importantly, only the things I want. Even if we dismiss vim's editing capabilities and its native integration with the wider linux ecosystem (tmux, zsh, ssh, etc), the best part about vim is that it's a blank slate that you can build into an IDE that's highly tuned to the work you do and the way you think, rather than trying to shoehorn every new IntelliJ feature into your workflow just because it exists in an IDE dropdown menu.
I don't begrudge anyone that says "wow, I don't want to take the time to research every damn feature of my IDE, just let me work", that's totally reasonable, and any of those IDEs will let you get the job done - for me - the time invested is worth it because of how much of my life is spent editing files on my computer.
I don't begrudge anyone that says "wow, I don't want to take the time to research every damn feature of my IDE, just let me work", that's totally reasonable, and any of those IDEs will let you get the job done - for me - the time invested is worth it because of how much of my life is spent editing files on my computer.
I tried hard for a few months to be efficient with vim. At the end, I was still faster with a laptop keyboard and trackpad for selecting and editing text at arbitrary places in a document ("random access editing").
One case where I find a mouse/trackpad essential: editing LaTeX documents. Being able to control-click to jump between a spot in the compiled .pdf and the corresponding source code, or the reverse, is invaluable (a feature supported in TeXShop, for instance). I realize that one can probably set up a similar system in vim. But, the appeal of vim for me was that, at the cost of learning a bunch of arcane keyboard shortcuts, I could go mouseless and as a consequence be faster. If I'm going to keep the mouse, the value proposition seems a lot worse.
One case where I find a mouse/trackpad essential: editing LaTeX documents. Being able to control-click to jump between a spot in the compiled .pdf and the corresponding source code, or the reverse, is invaluable (a feature supported in TeXShop, for instance). I realize that one can probably set up a similar system in vim. But, the appeal of vim for me was that, at the cost of learning a bunch of arcane keyboard shortcuts, I could go mouseless and as a consequence be faster. If I'm going to keep the mouse, the value proposition seems a lot worse.
Then use your mouse to highlight and do random access editing in vim? this has worked just fine for ~20 years.
Source: my experience of using vim for the last ~20 years
Source: my experience of using vim for the last ~20 years
Popularity is not a good a metric for comparing value. If we were to use it for choosing where to shop, the top choice would be Walmart [0]. This isn't to say that VSCode is bad, just that Vi/Vim being less popular doesn't mean it's not worth it for anyone to learn. It's also good to have a healthy field of tools to pick from. Plus, learning Vi to a degree that is productive takes a week of use, and then the keybindings can be applied elsewhere, such as VSCode.
[0] https://nrf.com/resources/top-retailers/top-100-retailers/to...
[0] https://nrf.com/resources/top-retailers/top-100-retailers/to...
So, don't learn vim because it's marketahare is "small"? Larger than xcode, atom, sublime and even notepad++ when you add neovim? That logic makes no sense and even if it did, the chart you linked still shows vim to be one of the largest is the world
> you have to reconfigure basic keybinds like the arrow keys "because it could break a system not used since the 1970s!"
Never had to do that on Nixos, Ubuntu, Amazon Linux, RHEL, MacOS or WSL
For my workflow with lots of context switching between code and commands, using only a terminal is more efficient use of my time. VSCode cannot do that in a way that works for me
But ignoring all of that, many use [neo]vim because they simply enjoy it. Enjoyment does not need justification
> you have to reconfigure basic keybinds like the arrow keys "because it could break a system not used since the 1970s!"
Never had to do that on Nixos, Ubuntu, Amazon Linux, RHEL, MacOS or WSL
For my workflow with lots of context switching between code and commands, using only a terminal is more efficient use of my time. VSCode cannot do that in a way that works for me
But ignoring all of that, many use [neo]vim because they simply enjoy it. Enjoyment does not need justification
> Reminder: VSCode, Visual Studio, IntelliJ, and Notepad++ all individually have a higher usage share among professional programmers
This is an artifact of the structure of the question. They're not asking what you use the most, they're asking what you use at all. Check all that apply.
So then you check Notepad++ even if you're a Linux developer who primarily uses vim or emacs but have Notepad++ on your rarely used Windows VM. You check Visual Studio or VS code if you had to contribute to an existing project which is tied to its build system, even if you avoid it whenever possible.
A quarter of all developers use vim. That's not a small number and it's not for no reason.
This is an artifact of the structure of the question. They're not asking what you use the most, they're asking what you use at all. Check all that apply.
So then you check Notepad++ even if you're a Linux developer who primarily uses vim or emacs but have Notepad++ on your rarely used Windows VM. You check Visual Studio or VS code if you had to contribute to an existing project which is tied to its build system, even if you avoid it whenever possible.
A quarter of all developers use vim. That's not a small number and it's not for no reason.
Something like this website doesn't teach you vim, it teaches you vi keybindings and the basic concepts. Vim bindings are available in all the editors you mentioned (although my understanding is that the Notepad++ bindings in particular are bad). For the people who say they're using vim productively, they're usually running some combination of plugins (that hopefully don't step on each others toes) that emulate the featureset of an IDE that they want to use.
And you're bang on wrt nano existing everywhere vim does!
And you're bang on wrt nano existing everywhere vim does!
You should lookup Argumentum ad populum. There are still many reasons to use a free and open source keyboard centric editor that can run as a TUI, has stayed around for 30 years while other Microsoft owned editors died on the vine barely 5 years into their lifespan.
If my professional opinion, learning vim or emacs will give you a tool that will last you several lifetimes and can grow with you as you customize it to your specific needs.
If my professional opinion, learning vim or emacs will give you a tool that will last you several lifetimes and can grow with you as you customize it to your specific needs.
So true! When I started as a professional programmer they were using Eclipse, then Textmate was the big thing, then it was all about SublimeText and now it seems everybody has moved to VSCode. And here I am still using Vim happily after 20 years...
I agree, don't use vim the text editor. But please, give a try to vim the editing paradigm, supported by all those programs or a reason via plugins.
> but it is already on your server
This is indeed not a good reason to learn Vim nowadays indeed. Vi has more chance to be present than nano on a stripped image by the way but I digress.
For me Vim started to make sense when remote work has begun to be the new normal. VPNs make with remote desktops make everything slower. I worked in places where we had to use two VPNs at the same time. Then I saw the hacker wizard kid using vim like he was Edward Scissorhands and how much more productive he was.
This is indeed not a good reason to learn Vim nowadays indeed. Vi has more chance to be present than nano on a stripped image by the way but I digress.
For me Vim started to make sense when remote work has begun to be the new normal. VPNs make with remote desktops make everything slower. I worked in places where we had to use two VPNs at the same time. Then I saw the hacker wizard kid using vim like he was Edward Scissorhands and how much more productive he was.
I use VSCode, IntelliJ and Notepad++ all with VIM mode. VIM isn't just the editor, it's a style of editing.
Honestly if an editor doesn't have VIM mode, I don't use it.
Honestly if an editor doesn't have VIM mode, I don't use it.
Nano and almost everything here you listed (without vim bindings) are not modal editors.
Here's some other professional advice: people liked vim because it is modal, that means the coding process itself can be automated, scripted on, insanely fast and can completely forego mouse/touchpad input.
Vim bindings by themselves are great, but they are not fully vim, for instance, most vim bindings including this website does not support `:norm`
Here's some other professional advice: people liked vim because it is modal, that means the coding process itself can be automated, scripted on, insanely fast and can completely forego mouse/touchpad input.
Vim bindings by themselves are great, but they are not fully vim, for instance, most vim bindings including this website does not support `:norm`
I use VSCode. And vim. Every day. Am I a VSCode user or a vim user? Probably the former (my usage is slightly higher, but not significantly).
I suspect some variation is the same for many; it's a likely driver of demand for vim bindings (which are ubiquitous).
Even if people's daily usage of vim is much lower than their GUI-IDE of choice, the aggregate is likely far higher than reported.
I suspect some variation is the same for many; it's a likely driver of demand for vim bindings (which are ubiquitous).
Even if people's daily usage of vim is much lower than their GUI-IDE of choice, the aggregate is likely far higher than reported.
The survey cited allowed you to select multiple. So your assumptions about what the data shows isn't based. Here is the question text:
> Which development environments did you use regularly over the past year, and which do you want to work with over the next year? Please check all that apply.
Pretty fair question if I've ever seen one.
> Which development environments did you use regularly over the past year, and which do you want to work with over the next year? Please check all that apply.
Pretty fair question if I've ever seen one.
[deleted]
That survey is potentially very biased -- 92% of professional developers are male?
That's the real number.
Here are is a comment for learning vim.
Open up terminal
vimtutor
Enjoy the tutorial
Open up terminal
vimtutor
Enjoy the tutorial
Vim is unnatural. It basically boils down to writing programming language commands to edit text. For example 4dd to delete 4 lines. Now, why exactly would I want to go into edit mode to type 4dd to delete 4 lines instead of select and delete.
It's just our minds don't work that way when thinking about editing text. The way I view text is visual. I don't think in terms of delete 4 lines, go line 435 and dw to delete a word. Copying and pasting text is a nightmare. Navigating from insert mode to visual mode to select and paste text. It's impossible to design a less intuitive text-editor.
It's just our minds don't work that way when thinking about editing text. The way I view text is visual. I don't think in terms of delete 4 lines, go line 435 and dw to delete a word. Copying and pasting text is a nightmare. Navigating from insert mode to visual mode to select and paste text. It's impossible to design a less intuitive text-editor.
> It's impossible to design a less intuitive text-editor.
Intuitiveness (or lack thereof) isn't a strong reason for dissuading use of a tool that you'll be using over a lifetime. Any tool you're using that you hope to be competent in requires learning and practice to become proficient in.
> It's just our minds don't work that way when thinking about editing text. The way I view text is visual. I don't think in terms of delete 4 lines, go line 435 and dw to delete a word.
Visually, if you want to delete a paragraph, how would you go about that? In most text editors you might grab your mouse and click on one end and drag through to the other end of the text and press backspace. In vim you can just tell your editor to delete the paragraph. Or maybe you want to change what's inside the parentheses, so you tell your editor you want to change what's inside the parentheses and you do that. If anything, the 'normal' way of text editing has almost nothing to do with how my mind models editing text while vim allows me to tell the editor exactly what I want it to do and it performs it.
Intuitiveness (or lack thereof) isn't a strong reason for dissuading use of a tool that you'll be using over a lifetime. Any tool you're using that you hope to be competent in requires learning and practice to become proficient in.
> It's just our minds don't work that way when thinking about editing text. The way I view text is visual. I don't think in terms of delete 4 lines, go line 435 and dw to delete a word.
Visually, if you want to delete a paragraph, how would you go about that? In most text editors you might grab your mouse and click on one end and drag through to the other end of the text and press backspace. In vim you can just tell your editor to delete the paragraph. Or maybe you want to change what's inside the parentheses, so you tell your editor you want to change what's inside the parentheses and you do that. If anything, the 'normal' way of text editing has almost nothing to do with how my mind models editing text while vim allows me to tell the editor exactly what I want it to do and it performs it.
>In most text editors you might grab your mouse and click on one end and drag through to the other end of the text and press backspace. In vim you can just tell your editor to delete the paragraph. Or maybe you want to change what's inside the parentheses, so you tell your editor you want to change what's inside the parentheses and you do that. If anything, the 'normal' way of text editing has almost nothing to do with how my mind models editing text while vim allows me to tell the editor exactly what I want it to do and it performs it.
That's the problem with telling the editor to do exactly what you tell it to do. Telling a machine to do exactly what you want is programming. For text editing doing what I want with 95% percent precision is more than enough. If that fails I can press CTRL + Backspace to delete few more words. How would you delete a paragraph in vim? I reckon something like:
1) Visually see the line where the paragraph is
2) Jump to that line with 100 gg
3) Run another command to delete the paragraph. Now again some thinking needs here is it a code block between curly braces {} or is it a textual paragraph but why is that thinking required when I can actually see it in front of me and select it.
4) Get back to insert mode
In a normal text-editor:
1) Visually see the line and select it with cursor and delete it.
That's the problem with telling the editor to do exactly what you tell it to do. Telling a machine to do exactly what you want is programming. For text editing doing what I want with 95% percent precision is more than enough. If that fails I can press CTRL + Backspace to delete few more words. How would you delete a paragraph in vim? I reckon something like:
1) Visually see the line where the paragraph is
2) Jump to that line with 100 gg
3) Run another command to delete the paragraph. Now again some thinking needs here is it a code block between curly braces {} or is it a textual paragraph but why is that thinking required when I can actually see it in front of me and select it.
4) Get back to insert mode
In a normal text-editor:
1) Visually see the line and select it with cursor and delete it.
> How would you delete a paragraph in vim? I reckon something like: <snip>
I think more experienced vim users would use "dip" for text (<d>elete <i>n <p>aragraph) or "di}"/"di{" (<d>elete <i>n <brace>) for stuff in braces.
If you want to change something instead? "cip" (<c>hange <i>n <p>aragraph) or "ci{"/"ci}" (<c>hange <i>n <braces>).
I think more experienced vim users would use "dip" for text (<d>elete <i>n <p>aragraph) or "di}"/"di{" (<d>elete <i>n <brace>) for stuff in braces.
If you want to change something instead? "cip" (<c>hange <i>n <p>aragraph) or "ci{"/"ci}" (<c>hange <i>n <braces>).
This is just making it all the more apparent that you didn't really grok vim while you were using it. to get to a paragraph you can use navigation keys, you can click on it with your mouse, you can jump to a line directly by its number, relative or absolute, you can search for a snippet of text inside of it. There's a myriad of ways you can move your cursor so that you can perform actions on a specific block of text, which includes the way you would do so in a normal text editor.
> Now again some thinking needs here is it a code block between curly braces {} or is it a textual paragraph but why is that thinking required when I can actually see it in front of me and select it.
There is almost no overhead to performing this action when you are even modestly proficient in vim, no more than the cognitive load it takes you to decide you must use a mouse to select that portion of text, which also requires more precision since you must accurately place the cursor both at the start and end points.
> Now again some thinking needs here is it a code block between curly braces {} or is it a textual paragraph but why is that thinking required when I can actually see it in front of me and select it.
There is almost no overhead to performing this action when you are even modestly proficient in vim, no more than the cognitive load it takes you to decide you must use a mouse to select that portion of text, which also requires more precision since you must accurately place the cursor both at the start and end points.
Again going to a line with cursor is not even enabled by default on vim. Instead we have to add "set mouse=a" in .vimrc. I guess it's a luxury to be able to do that so one needs to lookup online for how to enable very basic and core features.
You had to learn how to use a cursor at some point in your life and you had to learn how to edit text in the fashion that you do as well.
>How would you delete a paragraph in vim? I reckon something like ...
`dip` will delete all contiguous lines (ie: lines between blanks) `cip` will change in paragraph, (delete text and then put you in insert mode)
Here's another one: if the cursor is in the middle of a line, and you want to delete the rest of the line to change it, do you click and drag the mouse? Our do you hold shift, press down, backspace, and then press up again to get back to where you were?
I just press `C`
The vim "every key is a command" mode is called `normal` for a reason
`dip` will delete all contiguous lines (ie: lines between blanks) `cip` will change in paragraph, (delete text and then put you in insert mode)
Here's another one: if the cursor is in the middle of a line, and you want to delete the rest of the line to change it, do you click and drag the mouse? Our do you hold shift, press down, backspace, and then press up again to get back to where you were?
I just press `C`
The vim "every key is a command" mode is called `normal` for a reason
Vim feels very natural when you grok it.
> Now, why exactly would I want to go into edit mode to type 4dd to delete 4 lines instead of select and delete.
Because it's faster and more flexible.
> The way I view text is visual.
Vim allows you to select text easily. For example V4j will select this and the 4 lines below, vi{ will select all lines between curly brackets and vt( will select characters from this up to the character before (.
> Copying and pasting text is a nightmare.
Copying and pasting text is a bliss.
> It's impossible to design a less intuitive text-editor.
The learning curve is steep for sure, but with a little bit of effort you will edit text in a more convenient, flexible and faster way than before.
> Now, why exactly would I want to go into edit mode to type 4dd to delete 4 lines instead of select and delete.
Because it's faster and more flexible.
> The way I view text is visual.
Vim allows you to select text easily. For example V4j will select this and the 4 lines below, vi{ will select all lines between curly brackets and vt( will select characters from this up to the character before (.
> Copying and pasting text is a nightmare.
Copying and pasting text is a bliss.
> It's impossible to design a less intuitive text-editor.
The learning curve is steep for sure, but with a little bit of effort you will edit text in a more convenient, flexible and faster way than before.
> For example 4dd to delete 4 lines. Now, why exactly would I want to go into edit mode to type 4dd to delete 4 lines instead of select and delete.
The thing is that you can do both in Vim. 4dd is faster but harder to learn and commit to, it's not in any way required though and you can stick to vim basics and go the regular select and delete route too (via mouse, v, etc.)
The thing is that you can do both in Vim. 4dd is faster but harder to learn and commit to, it's not in any way required though and you can stick to vim basics and go the regular select and delete route too (via mouse, v, etc.)
But those are features of vim. The default settings of vim are nonexistent. I needed to spend hours just to get it to sort of work. It was not even showing line numbers let alone syntax highlighting.
I needed to spend hours just to get it to sort of work.
Some people consider this a bug, others consider it a feature.
I use both VS Code and (Neo)Vim on a regular basis. A huge advantage of VS Code is that for many languages, it works pretty darn well out of the box. I do a lot of ECMAScript development, and I have exactly two extensions installed for VS Code: ESlint and GitLens (plus some themes, but I don't consider those functional). My init.vim file is nearly 400 lines long, and that includes everything to provide a reasonable IDE-like experience (fuzzy finder, Ctrl-P, NerdTree, Airline, Git, various mappings, etc). Granted, I did not type all 400 lines (that is, they are copied from other user's configuration files), but I still stitched a lot together. And that's fine, for me. I get that some people don't want to spend their time tweaking their tools to that degree. VS Code is still a convivial tool[0], in my opinion. It simply starts from a different place.
[0] https://en.wikipedia.org/wiki/Tools_for_Conviviality
Some people consider this a bug, others consider it a feature.
I use both VS Code and (Neo)Vim on a regular basis. A huge advantage of VS Code is that for many languages, it works pretty darn well out of the box. I do a lot of ECMAScript development, and I have exactly two extensions installed for VS Code: ESlint and GitLens (plus some themes, but I don't consider those functional). My init.vim file is nearly 400 lines long, and that includes everything to provide a reasonable IDE-like experience (fuzzy finder, Ctrl-P, NerdTree, Airline, Git, various mappings, etc). Granted, I did not type all 400 lines (that is, they are copied from other user's configuration files), but I still stitched a lot together. And that's fine, for me. I get that some people don't want to spend their time tweaking their tools to that degree. VS Code is still a convivial tool[0], in my opinion. It simply starts from a different place.
[0] https://en.wikipedia.org/wiki/Tools_for_Conviviality
It's just our minds don't work that way when thinking about editing text
Please speak for yourself, sir. I do 2-5 line rearrangements and jumps very often and hate to do “home home shift+ down down down shift- ctrl_x scroll scroll scroll scroll …” instead of “4dd'a”. When it’s hard to count lines, you can “V/something<CR>” or “V30j” and adjust with jk to select more or less. When it’s a block, “%v%”. Vim always has less-movement ways even when you can’t calculate precisely and my mind can’t work in a “wait for 50 key-repeats” mode.
But I’ve felt what you’re describing at the time when my knowledge was shallow and I didn’t really know the essential part of vim.
It's impossible to design a less intuitive text-editor.
This one I agree with.
Please speak for yourself, sir. I do 2-5 line rearrangements and jumps very often and hate to do “home home shift+ down down down shift- ctrl_x scroll scroll scroll scroll …” instead of “4dd'a”. When it’s hard to count lines, you can “V/something<CR>” or “V30j” and adjust with jk to select more or less. When it’s a block, “%v%”. Vim always has less-movement ways even when you can’t calculate precisely and my mind can’t work in a “wait for 50 key-repeats” mode.
But I’ve felt what you’re describing at the time when my knowledge was shallow and I didn’t really know the essential part of vim.
It's impossible to design a less intuitive text-editor.
This one I agree with.
Vim has a visual mode that you may find more intuitive. I use it all the time for multi-line editing, particularly through the `V` command.
[deleted]
vim.so, openvim.com, vim-adventures.com, and now vim.is which looks weirdly similar?
Lots of people think learning vim is learning random letter-command mappings. This is true to some extent, but the idea that you're ONLY memorizing these mappings is not the right conceptualization, IMO. Instead, you are ingraining physical motion. The same way you don't think about how you're inserting your car key, or brushing your teeth, or walking, I don't think about pressing `o` to create a newline or pressing `CTRL-[` to cancel an operation. Maybe at the start I did that, but now I (barely) think "create a newline" and my fingers just DO it. Only when I'm substituting or recording a macro do I actually have to be careful. Otherwise? Pure physical motion.
This is true to the point that when someone asks me to explain how to do something that I do all the time I feel confused and it requires me significant effort to reverse engineer my muscle memory so I can verbalize the correct keystrokes.
Recording a macro is probably easier than to decode that physical memory haha.
[deleted]
website you cannot leave without asking another website
which you can't do because you can't leave the first one
which you can't do because you can't leave the first one
I'm finally gonna rant about Vim here. Gets way more credit than it is worth! ("but it's soooo coool! I'm superfast doing find / replace! You just gotta learn the crazy syntax, haha!") My response: "are you sure? I wouldn't rely on those fancy commands... best to use a statically typed language and rely on an abstract syntax tree for renaming tasks than an editor to do that."
Like everything in the software world, because some Google engineers used it, it became world wide famous. There's a saying in german that I love, basically amounting to, "they also cook with water". In short, there is no real tool that has "secret sauce" or is "super magical". It's an editor, that's all.
Say what you will but nano is is fine for me via SSH, VS Code for everything else.
Looks like many of the comments take a similar stance, which I'm actually surprised at.
Like everything in the software world, because some Google engineers used it, it became world wide famous. There's a saying in german that I love, basically amounting to, "they also cook with water". In short, there is no real tool that has "secret sauce" or is "super magical". It's an editor, that's all.
Say what you will but nano is is fine for me via SSH, VS Code for everything else.
Looks like many of the comments take a similar stance, which I'm actually surprised at.
> Like everything in the software world, because some Google engineers used it, it became world wide famous.
I'm skeptical to this claim because vi/vim's widespread usage predate google itself, by decades. It used to be the only way to really edit something in the 1980s on unix systems, unless you preferred ed.
Vim's modal system extends way beyond some special cases. The most time save I have using it are probably not fancy stuff but quick movement across lines and within lines.
I'm skeptical to this claim because vi/vim's widespread usage predate google itself, by decades. It used to be the only way to really edit something in the 1980s on unix systems, unless you preferred ed.
Vim's modal system extends way beyond some special cases. The most time save I have using it are probably not fancy stuff but quick movement across lines and within lines.
I'll see your "are you sure?" and raise you one. :) Are you sure that vi/vim have many people who use them and that those tools are "world wide famous" because of such superficial reasons? Isn't it possible (and far more likely) that there is some substance to their reasons?
Use whatever tool works best for you. I use vim because it is far and away the most efficient way to edit text - especially code. Anytime I have to use something else it's amazing how sluggish and tedious it feels to do the most basic operations - it feels a lot like trying to run in knee-deep water. I've extensively used many (most?) of the major editors on the planet (including many obscure ones) over several decades. I had to be forced to use vim at first because it seemed so terrible. Believe me, it's not my editor of choice because of some randos at Google, haha.
Use whatever tool works best for you. I use vim because it is far and away the most efficient way to edit text - especially code. Anytime I have to use something else it's amazing how sluggish and tedious it feels to do the most basic operations - it feels a lot like trying to run in knee-deep water. I've extensively used many (most?) of the major editors on the planet (including many obscure ones) over several decades. I had to be forced to use vim at first because it seemed so terrible. Believe me, it's not my editor of choice because of some randos at Google, haha.
Vi(m) predates Google by about.. 30? Years.
The rest of your post is fine though. You do you :)
The rest of your post is fine though. You do you :)
Author of another [1]vim learning tool here.
I launched it 10 months ago on [2]HN and that launch ended up leading me down the path to start a company and get accepted into YC.
It's cool to see other people's take on a problem but this feels eerily similar to my tool, down to some of the copy, layout, and pricing.
[1] https://www.vim.so
[2] https://news.ycombinator.com/item?id=25846347
I launched it 10 months ago on [2]HN and that launch ended up leading me down the path to start a company and get accepted into YC.
It's cool to see other people's take on a problem but this feels eerily similar to my tool, down to some of the copy, layout, and pricing.
[1] https://www.vim.so
[2] https://news.ycombinator.com/item?id=25846347
Is this not just a clone of vim.so??
I first created this vi quickstart tutorial at the request of two Windows sysadmin friends who were given charge of a few Unix servers. They later told me that it helped them come up to speed with text editing on Unix.
https://mobile.twitter.com/vasudevram/status/124858356689776...
https://mobile.twitter.com/vasudevram/status/124858356689776...
Can anyone of the "old" group explain what the benefit of vim is, if we have nano now? Having missed the days when only vim was there, I find it perplexing that vim is sometimes suggested. Personally, I have to look up each single keystroke in vim when nano just seems to follow common UX conventions.
It boils down to speed of editing text, especially editing code - I've yet to find anything that comes even remotely close (and for a long time I tried to find something else, haha).
Maybe one challenge in grasping it is that if you look at any one feature in isolation, it sorta looks like a negligible amount of time savings (if at all), and at the cost of weird key combinations. So maybe instead imagine if you took the top 200 common actions you do when editing code and recognize that over your career you might perform those actions many, many millions of times. Now shave 100ms to 5000ms (or more in some cases) off of each one.
I dunno if that helps, but anytime I have to use something other than vim, it's incredible how slow and tedious it is to do even the most basic things, and it feels exponentially worse with any sort of bigger editing tasks.
Maybe one challenge in grasping it is that if you look at any one feature in isolation, it sorta looks like a negligible amount of time savings (if at all), and at the cost of weird key combinations. So maybe instead imagine if you took the top 200 common actions you do when editing code and recognize that over your career you might perform those actions many, many millions of times. Now shave 100ms to 5000ms (or more in some cases) off of each one.
I dunno if that helps, but anytime I have to use something other than vim, it's incredible how slow and tedious it is to do even the most basic things, and it feels exponentially worse with any sort of bigger editing tasks.
Alright, I get this. Thanks for the explanation. I am using VS Code these days, which is why I have no need to use nano/vim for editing code (beyond setting of basic config settings, where speed does not really matter).
See jasode's answer above[1] and make sure to follow the stackoverflow link too[2]
[1] https://news.ycombinator.com/item?id=29432611
[2] https://stackoverflow.com/questions/1218390/what-is-your-mos...
Not stated in the other replies to your question: Vi is available on pretty much any UNIX derivative OS, and many other platforms. You can learn it once on your platform of choice, and then when you find yourself using some new (or old) platform that you are unfamiliar with, you will at least know how to edit a file.
I paid for vim.so. It was helpful to learn the most basic commands but I wish it had more exercises.
I don't think there is any point in using vim over an IDE but it is often quicker to edit config files in vim or navigate text so I use it for that.
I don't think there is any point in using vim over an IDE but it is often quicker to edit config files in vim or navigate text so I use it for that.
> Not an editor command ":q"
Boo!
Seriously though, love the project!
Boo!
Seriously though, love the project!
Long time VI(M) user here, probably starting in the 80's. I don't think it's the best, nor do I think it's for everyone. It's just what I'm comfortable with at a deep memory muscle level.
And a confession - I probably only use 25% of what its capabilities are. And some of what I do is totally "wrong" like when not inserting I use K for up, Enter to go down and space to go right. If I want to go to the beginning of a line, I hit enter (down) which takes me to the beginning of the next line. Then K (up) to get to the line. Totally "wrong" but it's what I've done for years and do it without even thinking about it.
It kind of brings to mind this bit from the first Perl State of the Onion...
"...I believe that learnability is a laudable goal, but frequently misplaced. The purpose of a language is not to help you learn the language, but to help you learn other things by using the language. We don’t water down English to make it easy to learn. We prefer English to remain a rich language, quirky, sloppy, and full of redundancy. Same for Perl.
A corollary to that is, while we don’t water down the language itself, we do allow people to speak subsets of the language. We don’t expect a five-year-old to speak with the same diction as a fifty-year-old. We don’t expect a native German speaker to use the same subset of English as a native Mandarin speaker. Similarly, we don’t look down on people for using subsets of Perl. There are certainly enough of them. You can write Perl programs that resemble sed, or awk, or C, or Lisp, or Python. This is Officially Okay in Perl culture. By way of contrast, try writing in the C subset of C++ and they’ll make a laughingstock of you."
And a confession - I probably only use 25% of what its capabilities are. And some of what I do is totally "wrong" like when not inserting I use K for up, Enter to go down and space to go right. If I want to go to the beginning of a line, I hit enter (down) which takes me to the beginning of the next line. Then K (up) to get to the line. Totally "wrong" but it's what I've done for years and do it without even thinking about it.
It kind of brings to mind this bit from the first Perl State of the Onion...
"...I believe that learnability is a laudable goal, but frequently misplaced. The purpose of a language is not to help you learn the language, but to help you learn other things by using the language. We don’t water down English to make it easy to learn. We prefer English to remain a rich language, quirky, sloppy, and full of redundancy. Same for Perl.
A corollary to that is, while we don’t water down the language itself, we do allow people to speak subsets of the language. We don’t expect a five-year-old to speak with the same diction as a fifty-year-old. We don’t expect a native German speaker to use the same subset of English as a native Mandarin speaker. Similarly, we don’t look down on people for using subsets of Perl. There are certainly enough of them. You can write Perl programs that resemble sed, or awk, or C, or Lisp, or Python. This is Officially Okay in Perl culture. By way of contrast, try writing in the C subset of C++ and they’ll make a laughingstock of you."
The best way to learn vim is to use vim.
Another shark preying on lazy wannabe vimmers.
Obviously a clone of vim.so
Blatant rip-off of https://www.vim.so beware
[deleted]
I would like to point out: vim is a text editor. It exists to edit text. This is all it does. That's it. It is not an IDE. Maybe you can mangle neovim into an IDE shape, but not vim, not really.
Lots of complaints here boil down to "I can't [insert IDE feature here, e.g. use a debugger]". Of course you can't. You'd have a bad time using a hammer to put in a screw, too. But you can sure use a hammer to put in a nail.
If you want text editing, use vim. If you want an IDE, use Emacs, or VSCode, or whatever. Just don't complain about the hammer when you actually need a screwdriver.
Lots of complaints here boil down to "I can't [insert IDE feature here, e.g. use a debugger]". Of course you can't. You'd have a bad time using a hammer to put in a screw, too. But you can sure use a hammer to put in a nail.
If you want text editing, use vim. If you want an IDE, use Emacs, or VSCode, or whatever. Just don't complain about the hammer when you actually need a screwdriver.
Not a neovim user, but given that it has built-in LSP support it doesn’t seem too far off from the features of VSCode.