Interactive Vim tutorial(openvim.com)
openvim.com
Interactive Vim tutorial
http://www.openvim.com
229 comments
Sorry, but I think that's really bad advice.
For one thing, it doesn't give new users any positive experience or reason to learn vim. If all you learn is to do things that are "pointless" (like learning hjkl), then you won't get any value out of vim. And if your way of learning is to do something that screws up your file and try to recreate how that happened, well, let's just say that every time I do something that screws up my file I'm in the middle of working, and the last thing I want is to stop and fix some random problem.
I usually recommend people try to get into vim easily, then learn the GOOD things. I.e. I think it's perfectly fine that people start with arrow keys, much as I love hjkl. But to get value out of vim, you should really learn "f" and "t", and text objects, then how they compose with "c" and "d". That is the reason I started loving vim myself - that's when I saw that it gives me something that other editors didn't give me, adn that encouraged me to explore further.
For one thing, it doesn't give new users any positive experience or reason to learn vim. If all you learn is to do things that are "pointless" (like learning hjkl), then you won't get any value out of vim. And if your way of learning is to do something that screws up your file and try to recreate how that happened, well, let's just say that every time I do something that screws up my file I'm in the middle of working, and the last thing I want is to stop and fix some random problem.
I usually recommend people try to get into vim easily, then learn the GOOD things. I.e. I think it's perfectly fine that people start with arrow keys, much as I love hjkl. But to get value out of vim, you should really learn "f" and "t", and text objects, then how they compose with "c" and "d". That is the reason I started loving vim myself - that's when I saw that it gives me something that other editors didn't give me, adn that encouraged me to explore further.
I have been using Vim for 15 years now and I completely agree with sevensor's comment.
- Vim is not newbie-friendly regardless of whether you remove guioptions or not. One has to spend at least a few hours of study and practice to get comfortable with Vim. If one is forced to invest a few hours to learn an editor, one might as well get rid of guioptions and follow other advice provided in sevensor's comment.
- Learning hjkl is not really pointless. hjkl and other motion commands makes Vim a unique and ergonomically a very superior experience. If one does not want to spend time learning hjkl and other motion keys, then one might as well skip learning Vim and pickup Emacs, Sublime Text or another capable editor.
- Vim is not newbie-friendly regardless of whether you remove guioptions or not. One has to spend at least a few hours of study and practice to get comfortable with Vim. If one is forced to invest a few hours to learn an editor, one might as well get rid of guioptions and follow other advice provided in sevensor's comment.
- Learning hjkl is not really pointless. hjkl and other motion commands makes Vim a unique and ergonomically a very superior experience. If one does not want to spend time learning hjkl and other motion keys, then one might as well skip learning Vim and pickup Emacs, Sublime Text or another capable editor.
You might be right. It's true that vim has a learning curve one way or another.
On the other hand, if I want to show someone the "good parts" of vim, I try to show them something they can't do in another editor, rather than something that they can do (arrow keys). Even if I 100% agree that arrow keys are a worse experience, it's just not as convincing as something that can't be done outside of vim.
At least in my experience.
On the other hand, if I want to show someone the "good parts" of vim, I try to show them something they can't do in another editor, rather than something that they can do (arrow keys). Even if I 100% agree that arrow keys are a worse experience, it's just not as convincing as something that can't be done outside of vim.
At least in my experience.
Yeah, but that's a good way to sell vim. Once you've shown someone vim and whet their appetite, it's probably best to show them about 2 or 3 features and let them fill in the blanks while being at least minimally productive.
I've recently taken this approach to emacs and org-mode. I'm a long-time vim user with a super-optimized vimrc, so I know what productivity feels like. I threw in spacemacs to reduce the learning curve, but I still was initially much less productive with org-mode and emacs than with markdown and vim for my TODO lists.
Now, after using org and emacs for three weeks, I'm at the point where several of the amazing features that I had heard about are in my bag of tricks, and it feels awesome! But I've barely tweaked my .spacemacs file, have only learned a bit of org, and am sure that I am nowhere near peak comfort/productivity/flow. But if I had tried to learn all of the things that I know are cool about org-mode, emacs, and spacemacs all at once, I wouldn't have gotten any work done over the past few weeks, and honestly I probably would have given up.
TL;DR: the fancy stuff is the best marketing, but it's best to start slow.
I've recently taken this approach to emacs and org-mode. I'm a long-time vim user with a super-optimized vimrc, so I know what productivity feels like. I threw in spacemacs to reduce the learning curve, but I still was initially much less productive with org-mode and emacs than with markdown and vim for my TODO lists.
Now, after using org and emacs for three weeks, I'm at the point where several of the amazing features that I had heard about are in my bag of tricks, and it feels awesome! But I've barely tweaked my .spacemacs file, have only learned a bit of org, and am sure that I am nowhere near peak comfort/productivity/flow. But if I had tried to learn all of the things that I know are cool about org-mode, emacs, and spacemacs all at once, I wouldn't have gotten any work done over the past few weeks, and honestly I probably would have given up.
TL;DR: the fancy stuff is the best marketing, but it's best to start slow.
Hmm, I've just decided to start slowly learning vim by adding some vim-like functionality to my browsers.
The best way to impress someone with vim is to do "shift+o" and "o"
I agree. I didn't really learn vim (and subsequently learn to love it) until I disabled the arrow keys in my .vimrc file, which forced me to learn hjkl.
I think we just don't agree about what the good parts of vim are. I find f and t to be a minute improvement over forward search. I think hjkl is strictly better than arrow keys, because you don't have to move your fingers from the home row to navigate a file, and I think the basic editing commands I outlined are sufficient for a superior editing experience within a day of learning them, no deep study required.
Forward search is probably my most used vim feature. /LOCATION<enter>c/NEXT_LOCATION<enter> and you can be in insert mode changing the content. The only thing you need to think about is the content you want to change. You don't think about how to get there, you don't think about how many times you need to hit arrow while holding down shift-alt, or the fact that it will always jump one too far and you'll need to shift-leftarrow back one.
Let me clarify, I absolutely love hjkl, and couldn't live without it (seriously - I built scripts just so the computer will always have hjkl as arrow keys, and many other vim goodies).
I just feel like it's a thing that people don't realize will help until they internalize it. Whereas almost everyone I show the text objects to immediately realizes their utility. I'm only looking at this from a pedagogical perspective.
I just feel like it's a thing that people don't realize will help until they internalize it. Whereas almost everyone I show the text objects to immediately realizes their utility. I'm only looking at this from a pedagogical perspective.
i'm sure it becomes intuitive with lots of use, bit i find it awkward with having to move my finger off the home keys to move left. somehow for me, its even more confusing that way. where as my arrow keys are completely intuitive, one finger for the left and right keys and the middle finger handles up down. to me its not a big deal to remove my fingers from the home row if i already have to move from the home keys.
[deleted]
So I've been thinking about this and your other responses in this thread, and I think I've figured out where our viewpoints differ, fundamentally. I think many people, yourself included, want to do more with an editor. That's your motivation for using vim, and so you pursue customization, advanced features, and relentlessly minimize keystrokes. (That's a plural you, by the way. I'm speaking to everyone advocating a bells-and-whistles approach to learning vim.) I want to emphasize that there's nothing wrong with this -- it's a perfectly valid frame of mind, but it's just not my frame of mind. In contrast, I want to think less about my editor. That is, I want editing text to be as automatic as touch-typing. I want for there to be as little friction between my mind and the screen as possible, so I don't want to learn new things about my editor any faster than I can incorporate them into the set of things I can do without thinking about them. As a result, I'm sure there are people who've been using vim for two weeks who know more features than I do after 20 years.
Anyhow, I'd be really interested to know if you agree with this characterization of your outlook.
Anyhow, I'd be really interested to know if you agree with this characterization of your outlook.
A lot of people learn vi out of necessity. Eventually, they have to SSH into a server and have to make minor changes to files where it's quicker to do it right there rather than use FTP or VCS. If that's the case, all you really need to know are the basics that the OP mentioned. After that, it's up to the person's personality to decide if there is value in learning further and more complicated commands.
> Sorry, but I think that's really bad advice [...] If all you learn is to do things that are "pointless" (like learning hjkl),
I agree. For navigation I rather use f, w, e, {,}, ctrl-l, ctrl-u, /, o. I think hjkl are overrated.
I agree. For navigation I rather use f, w, e, {,}, ctrl-l, ctrl-u, /, o. I think hjkl are overrated.
hjkl are the minimum keys needed to be able to move anywhere in vi[m], they're certainly not pointless.
Vim supports the cursor keys, even in insert mode.
Assuming the new Vim user already knows how those work, telling them that they instead need to go `Esc -> hjkl -> i` and ending things there... that's going to leave them worse off in Vim than saying nothing.
Assuming the new Vim user already knows how those work, telling them that they instead need to go `Esc -> hjkl -> i` and ending things there... that's going to leave them worse off in Vim than saying nothing.
I always recommend 'Your problem with Vim is that you don't grok vi.' to new users starting out in vim [0]. You can never learn about the language of vim too early.
[0] https://stackoverflow.com/a/1220118/2131903
[0] https://stackoverflow.com/a/1220118/2131903
That's a very informative link -- I can see how that might be helpful context for a new user. It's hard for me to get into that mental frame, since my first text editor was edlin for DOS. I'll stick by my recommendation to type first and study later, however. Experience is a powerful teacher.
Thank you for that link. I appreciate that he chose to intersperse the history of commands (such as grep!) within his explanation.
That was enlightening. Thanks for sharing!
`vimtutor` is where most people should start. It's bundled with every vim installation. Vimtutor teaches the absolute basics in an interactive manner so you'll remember the lessons.
I like the "Learn Vim Progressively" guide. It starts with just a few commands, and introduces new ones in small batches when you feel comfortable with the ones you're using.
http://yannesposito.com/Scratch/en/blog/Learn-Vim-Progressiv...
I'd add windows to your list of things to take a look at once you feel comfortable with the editor. You can split your workspace with ctrl+w followed by 'v' (vertical) or 's' (split). Then you can switch between those panes by pressing ctrl+w twice, or ctrl+w followed by hjkl or an arrow key. You can also resize the windows and stuff, it's great for things like viewing a header and source file at the same time.
http://yannesposito.com/Scratch/en/blog/Learn-Vim-Progressiv...
I'd add windows to your list of things to take a look at once you feel comfortable with the editor. You can split your workspace with ctrl+w followed by 'v' (vertical) or 's' (split). Then you can switch between those panes by pressing ctrl+w twice, or ctrl+w followed by hjkl or an arrow key. You can also resize the windows and stuff, it's great for things like viewing a header and source file at the same time.
I feel like window management is a good way to introduce vimscript as well. Lets you tweak some of the features like having the windows open on the right instead of left or getting rid of the w so it's just ctrl+{hjkl}.
I learned vi 20 years ago now, and vim a year or three later. In all that time, I've never seen the point to vimscript. If you want a heavily customized, scriptable editor, why just not use emacs? Vi works the way it works.
I missed my chance of learning vim properly and I never internalized h I j k. After trying a few episodes of forcing myself to use h I j k miserably, I question that wisdom. The fact is I never find arrow keys a hindrance, probably when I navigate with arrow keys, I am always unclear of my editing goals and I can use some slowdown thinking anyway
I'd argue that text objects are by far the biggest advantage vim has over other editing models. From my experience they are pretty easy to learn for programmers.
> i and ESC
I think i and Ctrl+[ is better? It's more in line with the idea of keeping your hands near home row.
I think i and Ctrl+[ is better? It's more in line with the idea of keeping your hands near home row.
It's a fair point. I learned ESC long years before ^[ and it's stuck in my muscle memory. But a new user might benefit from using ^[ instead. Some keyboards put F1 where ESC belongs, and my habit has been to remap F1 to NOP because help is so annoying, but maybe I should remap ESC to help. That would get me to switch over in short order.
I've remapped capslock to ESC. I can't remember ever wanting to use capslock mode since I first learned to touch type. Much easier to have Esc there. Or Backspace, Home, End, or delete are also good options.
Like sibling, I also mapped capslock to control. I use ^[ instead of ESC and there are other control-<whatever> shortcuts that are extremely useful, so it gets more utility than ESC would.
Of course, then I bought a kinesis advantage2 keyboard and now suddenly every key is easy to press, even the cursor keys.
Of course, then I bought a kinesis advantage2 keyboard and now suddenly every key is easy to press, even the cursor keys.
I mapped capslock to Control and use Control-c instead of escape. It's much easier on my pinky.
>learning to use x and d early on is probably also a good idea, if like me you're the kind of person who makes mistakes
Same with using 's'. Super handy when you accidentally type the wrong character.
Same with using 's'. Super handy when you accidentally type the wrong character.
I work at a company where we pair on everything. The feature that generally converts people is keyboard macros, after I use them to automatically perform some tedious code transformation.
I came to the comments after a bit of the tutorial to write something along the same lines but less eloquently. I absolutely agree, too much too fast.
My hackles were raised when it starts with "ESC" to enter normal mode and "i" for insert mode. Rather than "i" for insert mode and "ESC" to get out of insert mode. Also, I used the arrow keys to move around in vim for ages before I disabled them.
My hackles were raised when it starts with "ESC" to enter normal mode and "i" for insert mode. Rather than "i" for insert mode and "ESC" to get out of insert mode. Also, I used the arrow keys to move around in vim for ages before I disabled them.
totally agreed. the best way to learn vim is slowly. teach your self one thing a day and use it all day. if you keep using it great, if not move on to the next thing. otherwise you get brain overload and someone is trying to teach you how THEY use vim and you don't create your own style.
If you are relying on accidentally f'ing things up then u and ctrl-r are essential too.
u is my favourite!
u is my favourite!
As a heavy vim user for 15~ years I don't find h,j,k,l useful and for new users that may be one of the most confusing / alien changes.
I still find them useful, but they're just another navigation tool as opposed to the main navigational commands a newcomer might use them as. There are frequently situations where I can easily move next to the character I want to operate on and adjust the position with h or l.
Agreed, though arguably you need to tell newbs that in order to quit, they must type <Esc>:q!, not just :q!
"Mode confusion is a feature, not a bug." Just one reason why vim is the most overrated POS of all time.
> Mode confusion is a feature, not a bug.
Then you realize that insert mode is the least useful mode there is.
Then you realize that insert mode is the least useful mode there is.
All these tutorials are like taking beginner French. If you want to learn French live in France. If you want to learn Vim you have to live in it. Use it for your development full time. Then over time you start to see it's power.
For me on Windows, GVim was the only sane option. Mostly because the Windows console can't fully handle syntax highlighting / italics. However it's also a good transition world. You've got all the power of Vim but quite a few of the commands you'd expect still work. I've practically never need them but it's handy to reduce the confusion / frustration
For me on Windows, GVim was the only sane option. Mostly because the Windows console can't fully handle syntax highlighting / italics. However it's also a good transition world. You've got all the power of Vim but quite a few of the commands you'd expect still work. I've practically never need them but it's handy to reduce the confusion / frustration
I fully agree with you, however some people are worried by the loss of their daily productivity especially if they are used to using their mouse a lot, for those I will recommend to start learning vim in their browser to surf mouse-free using plugins like SurfingKeys[1], vimium[2](chrome), Vimperator[3](Firefox). Once used to surf without reaching to the mouse and know the essential vim key, you'll be ready to use vim daily for your dev work, without a big loss in initial productivity.
[1] https://github.com/brookhong/Surfingkeys
[2] https://vimium.github.io/
[3] https://addons.mozilla.org/en-US/firefox/addon/vimperator/
[1] https://github.com/brookhong/Surfingkeys
[2] https://vimium.github.io/
[3] https://addons.mozilla.org/en-US/firefox/addon/vimperator/
[deleted]
I cannot recommend SurfingKeys highly enough; it's a phenomenal extension.
I'm glad GVim works well for you in windows.
Personally I like the simplicity of characters-in-characters-out that comes with working with vim in a terminal. I also like to be able to exit to bash and do redirection trickery on my recently saved files. For these reasons, I avoid GVim.
MSYS2 (which uses MinTTY for its terminal) is what I use, and as far as I've noticed it supports all the bells and whistles that the windows terminal lacks.
Personally I like the simplicity of characters-in-characters-out that comes with working with vim in a terminal. I also like to be able to exit to bash and do redirection trickery on my recently saved files. For these reasons, I avoid GVim.
MSYS2 (which uses MinTTY for its terminal) is what I use, and as far as I've noticed it supports all the bells and whistles that the windows terminal lacks.
Yeah definitely, I regarded it as a failure to fall back to GVim. But my sanity and productivity was at stake.
I did spend a lot of time in Vim in DOS and loved the fact that it was even possible to do something productive there.
But I just started wasting more and more time on little details that didn't quite work.
It's even more frustrating when you compare to how perfectly it works in the Linux command line. Certainly in Linux I'll use regular Vim.
I've used very little of the GVim commands and got rid of the ugly menu so it looks like regular Vim.
But I have utmost respect for GVim for being forgiving and kind to a new user.
I did spend a lot of time in Vim in DOS and loved the fact that it was even possible to do something productive there.
But I just started wasting more and more time on little details that didn't quite work.
It's even more frustrating when you compare to how perfectly it works in the Linux command line. Certainly in Linux I'll use regular Vim.
I've used very little of the GVim commands and got rid of the ugly menu so it looks like regular Vim.
But I have utmost respect for GVim for being forgiving and kind to a new user.
GVim works quite well with Powershell. I used it heavily a year ago when I was on a console crusade.
Put this in your $profile and you can open it just by calling "vim":
Set-Alias vim "C:\Utilities\vim74\vim.exe"
Put this in your $profile and you can open it just by calling "vim":
Set-Alias vim "C:\Utilities\vim74\vim.exe"
Both powershell and the dos prompt still go through the console. It's quite amazing to have Vim running in a native Windows prompt but when you use it full time the little things start to get to you.
If you can't go to France start by changing all your locales to French. Computer, phone, TV, everything.
Sublime Text comes with a vim plugin. It isn't a perfect copy though.
The Ubuntu shell on Windows 10 comes with vim and syntax highlighting.
As far as I know, the Ubuntu shell still uses the console. There is indeed highlighting but basically only 8 colours that are dubiously split to make 16. A recent Windows update was supposed to give 256 colours but I tried and couldn't get it to work. Even then though you still haven't got bold or italics. It's these little things that I missed.
I use Mintty and it has 256 colors. Not sure about bold and italics.
Author here.
The tutorial succeeds if it gets people to have a superficial comprehension what Vim is about -- especially for those that have been putting off trying it out in a terminal. That's it. It doesn't really try to make you actually learn Vim.
As a tutorial it could be made so much better. I don't have the energy slots for this project. But I feel anxious when I get feedback because I feel like there's some moral duty to fix the site. The least I can do is to pay for the hosting so that people get to have a go with it as it seems some people like it.
Just to make clear: the Vim behaviour is modelled and is not just trivial precoding of keystream. There is a sandbox where you have contextual helper at the right side of the screen. You can play around with it to your heart's and battery's content. But it is merely a simplistic version of Vim.
Development-wise the most fun aspect of the tutorial was the DSL for tests. For some reason (haven't really updated the code properly in years) many fails. But click on the individual tests and you see something fun. http://openvim.com/tests.html See the corresponding code here: https://github.com/egaga/openvim/blob/87b9e1d62c4144c958ddf8...
The actual code is modelled operating on html elements. This was a fun side project, so please don't be too critical. It grew bigger than anticipated.
The tutorial succeeds if it gets people to have a superficial comprehension what Vim is about -- especially for those that have been putting off trying it out in a terminal. That's it. It doesn't really try to make you actually learn Vim.
As a tutorial it could be made so much better. I don't have the energy slots for this project. But I feel anxious when I get feedback because I feel like there's some moral duty to fix the site. The least I can do is to pay for the hosting so that people get to have a go with it as it seems some people like it.
Just to make clear: the Vim behaviour is modelled and is not just trivial precoding of keystream. There is a sandbox where you have contextual helper at the right side of the screen. You can play around with it to your heart's and battery's content. But it is merely a simplistic version of Vim.
Development-wise the most fun aspect of the tutorial was the DSL for tests. For some reason (haven't really updated the code properly in years) many fails. But click on the individual tests and you see something fun. http://openvim.com/tests.html See the corresponding code here: https://github.com/egaga/openvim/blob/87b9e1d62c4144c958ddf8...
The actual code is modelled operating on html elements. This was a fun side project, so please don't be too critical. It grew bigger than anticipated.
It's a really, really good piece of work. I hope you keep making tutorials.
I was impressed with the high ratio of useful content to time spent, and how the full tutorial only seemed to take 10 - 20 minutes.
I'm a 6 or 7 year vim veteran, and your tutorial taught me I could combine numbers with commands. I didn't know that!
For anyone reading and scoffing, please don't think I'm some vimless noob, I know %s/regex/replacement/g visual block selection and edit mode ( ctrl-shift-v, cursor, shift-i, double esc ), split mode :sp, and so on, but I never knew about the numbers with commands, nor about shift-X for left of cursor delete.
So even as someone experienced in vim ( and who codes in vim for everything ), this has improved my productivity!
Thank you so much, a great piece of work. Hope you keep making more tutorials on topics.
I was impressed with the high ratio of useful content to time spent, and how the full tutorial only seemed to take 10 - 20 minutes.
I'm a 6 or 7 year vim veteran, and your tutorial taught me I could combine numbers with commands. I didn't know that!
For anyone reading and scoffing, please don't think I'm some vimless noob, I know %s/regex/replacement/g visual block selection and edit mode ( ctrl-shift-v, cursor, shift-i, double esc ), split mode :sp, and so on, but I never knew about the numbers with commands, nor about shift-X for left of cursor delete.
So even as someone experienced in vim ( and who codes in vim for everything ), this has improved my productivity!
Thank you so much, a great piece of work. Hope you keep making more tutorials on topics.
Oh, that's informative to know--verifies my own perception--and makes me happy!
I appreciate your support. Thank you.
I appreciate your support. Thank you.
I started going through it, and unfortunately it takes control away from you way too often. I want to be able to toy around with the concepts after I learn them. I'd still recommend `vimtutor`.
I'd also recommend after vimtutor that you just keep a postit note on your monitor with a few commands. Replace it every week or two. You'll learn some commands you like and use all the time, others you'll forget because you don't use them. But it really makes it easy to become "an expert" really fast.
vimtutor is especially useful for beginners. Very interactive. Makes you want to learn more once you're done with it.
I remember reading this beautiful essay Seven habits of effective text editing by Bram Moolenaar, the main author of Vim.
http://www.moolenaar.net/habits.html
I remember reading this beautiful essay Seven habits of effective text editing by Bram Moolenaar, the main author of Vim.
http://www.moolenaar.net/habits.html
I agree, I really hated the fact that you could only try things out in exactly the ways prescribed. It makes sense, if you're writing a tutorial like that in javascript in the browser, you don't want to just rewrite Vim. But it makes it a pretty frustrating tutorial to follow and kind of beats of the point of it.
I like Vim adventures a lot. I think it's a better approach than this in a lot of ways.
I like Vim adventures a lot. I think it's a better approach than this in a lot of ways.
Exactly, often changes happen so quickly that you cannot really tell what happened. You need to try it a few times to get used to the concept.
'vim adventures' also seems fun, but it's not quite the same (for me) without the context of actually navigating a text document.
I picked up vim very well from vim adventures. Once I finished the game those key movements were in my muscle memory, and that’s all that was really needed to get me up and running.
> 'vim adventures' also seems fun, but it's not quite the same (for me) without the context of actually navigating a text document.
On https://news.ycombinator.com/item?id=14658197 and its children I wrote something about the business model of VIM Adventures that you should consider before buying.
On https://news.ycombinator.com/item?id=14658197 and its children I wrote something about the business model of VIM Adventures that you should consider before buying.
+1 for vimtutor. It's not really in dire need of replacement imo!
Vimtutor is great. For anyone who is vim shy but wants to learn I'd highly recommend setting a reminder every, oh, month maybe to just fire up vimtutor and go through it until you get bored or whatever. It's amazing how fast you'll pick it up.
The only real shortcoming of vimtutor is that it cuts off before taking really advanced topics like buffers and windows.
The only real shortcoming of vimtutor is that it cuts off before taking really advanced topics like buffers and windows.
Definitely. Beyond vimtutor, I've found Practical Vim to be a fantastic book. I strongly recommend that book once someone has the basics of vim down.
Here’s how I “learned” vim and many of the more proficient vimmers I know did too: go through vimtutor (type “vimtutor” on your command line), then write YOUR OWN .vimrc - in vim. Then use it and learn by doing.
I disagree with the notion that you have to write your own vimrc from scratch in order to become a proficient vim user. Don't waste your time pouring over the documentation and trying to get things just right, vim is a pretty old program and a lot of useful config options are not on by default, nor are they easy to understand by a skim of the documentation. There's no point to having a deep understanding of them, because you want them on 100% of the time.
Start by copying someone else's vimrc (vim-sensible [1] is a great starting point) and tweak it as needed. My $0.02 is to avoid plugins until you have used vim for a substantial amount of time.
[1]: https://github.com/tpope/vim-sensible/blob/master/plugin/sen...
Start by copying someone else's vimrc (vim-sensible [1] is a great starting point) and tweak it as needed. My $0.02 is to avoid plugins until you have used vim for a substantial amount of time.
[1]: https://github.com/tpope/vim-sensible/blob/master/plugin/sen...
I strongly disagree with your disagreement, but that's ok.
Writing my own vimrc from scratch (but obviously referencing others) was by far THE best learning tool for me.
Writing my own vimrc from scratch (but obviously referencing others) was by far THE best learning tool for me.
Completely agree -- did the same the other day at the insistence of another Dev.
It's simpler and better at imparting the minimum viable working knowledge of Vim than any online tutorial -- you don't even need a net connection or a web browser. I'm by no means a competent Vim user but I did have the basics after 30 minutes which is what it advertised.
It's simpler and better at imparting the minimum viable working knowledge of Vim than any online tutorial -- you don't even need a net connection or a web browser. I'm by no means a competent Vim user but I did have the basics after 30 minutes which is what it advertised.
Went through the tutorial, but I still don't think I really get why so many people seem to like Vim so much. The only thing there I noticed which was new to me from a functionality standpoint was the repeated commands feature.
Anyone have some better examples of things you can do with Vim that make it worth learning over a GUI-based editor like Atom?
Anyone have some better examples of things you can do with Vim that make it worth learning over a GUI-based editor like Atom?
There are a few things that I immediately notice are missing when switching back to normal text editing from vim:
ci( - Change inside parentheses ci" ci' ci}
If your cursor is anywhere inside a set of parentheses, (if, while, for, function call, aka this happens a lot) and you need to change everything inside the parentheses, just type ci( and it deletes everything inside the parens and puts you in insert mode so you can start typing. Guess what ci" and ci' do? How often do you need to rewrite a string? This is huge.
dd - Delete line
Deletes the whole line with a quick double tap of a home row key. So much faster than highlighting the whole line with the mouse and hitting backspace twice, or hitting home, shift+ctrl end, backspace backspace. Want to delete 3 lines? 3dd.
A
Move to the end of the current line and start typing. Super simple and nice to have.
w
Move to the beginning of the next word. Way more ergonomic than ctrl+right arrow.
yyp
Copy the current line and paste it below the current line. Super simple, super fast.
Those are the commands that make Vim matter to me. Once you put in the time to make them muscle memory, you'll never look back. There are of course tons of other commands, but I can say that those are the ones that changed how editing text feels to me.
ci( - Change inside parentheses ci" ci' ci}
If your cursor is anywhere inside a set of parentheses, (if, while, for, function call, aka this happens a lot) and you need to change everything inside the parentheses, just type ci( and it deletes everything inside the parens and puts you in insert mode so you can start typing. Guess what ci" and ci' do? How often do you need to rewrite a string? This is huge.
dd - Delete line
Deletes the whole line with a quick double tap of a home row key. So much faster than highlighting the whole line with the mouse and hitting backspace twice, or hitting home, shift+ctrl end, backspace backspace. Want to delete 3 lines? 3dd.
A
Move to the end of the current line and start typing. Super simple and nice to have.
w
Move to the beginning of the next word. Way more ergonomic than ctrl+right arrow.
yyp
Copy the current line and paste it below the current line. Super simple, super fast.
Those are the commands that make Vim matter to me. Once you put in the time to make them muscle memory, you'll never look back. There are of course tons of other commands, but I can say that those are the ones that changed how editing text feels to me.
I think the strongest arguments for vim are:
1. The main benefit of vim or any editor is not some fancy feature like macros or visual block editing. Although vim has those and they are great, they only become useful in about 20% of situations. When coding, you spend much more time reading code than writing it. That's why vim has you in Normal mode most of the time, where you can't type at all, and the whole keyboard becomes a tool for navigating. Reaching for the mouse incurs an unconscious mental cost that affects the way you read and write code. Editor ergonomics do impact your codebase.
2. Vim's ratio of power to learning difficulty is the best out there, because once you learn one word of vim's "language", you can combine it with every other word you know and it will behave how you expect.
3. I never try to convince people to switch to the actual vim editor because it requires a ton of customization just to be usable, and overall it's not that great. It's filled with cruft and weird things like a custom scripting language. The only important part is the key bindings, and you can get those in any modern editor. I use about 4 different editors and IDEs on 3 platforms on a daily basis. I never had to learn all their crappy keyboard shortcuts because they all have vim key bindings.
1. The main benefit of vim or any editor is not some fancy feature like macros or visual block editing. Although vim has those and they are great, they only become useful in about 20% of situations. When coding, you spend much more time reading code than writing it. That's why vim has you in Normal mode most of the time, where you can't type at all, and the whole keyboard becomes a tool for navigating. Reaching for the mouse incurs an unconscious mental cost that affects the way you read and write code. Editor ergonomics do impact your codebase.
2. Vim's ratio of power to learning difficulty is the best out there, because once you learn one word of vim's "language", you can combine it with every other word you know and it will behave how you expect.
3. I never try to convince people to switch to the actual vim editor because it requires a ton of customization just to be usable, and overall it's not that great. It's filled with cruft and weird things like a custom scripting language. The only important part is the key bindings, and you can get those in any modern editor. I use about 4 different editors and IDEs on 3 platforms on a daily basis. I never had to learn all their crappy keyboard shortcuts because they all have vim key bindings.
I have to disagree with #1, vim normal mode is emphatically not about navigation, it's about editing. It's basically a command grammar where navigation (motions in vim parlance) can be combined with the various commands.
The key observation behind its design is that programmers and sysadmins spend much more time editing than entering new text, and therefore it is asinine that 40 of the keys on the keyboard are permanently dedicated to typing out literals when there are very obvious editing operations that give you a lot more leverage.
The key observation behind its design is that programmers and sysadmins spend much more time editing than entering new text, and therefore it is asinine that 40 of the keys on the keyboard are permanently dedicated to typing out literals when there are very obvious editing operations that give you a lot more leverage.
Vim is really a combo effect, it's great when the commands are second nature and you think of your editing tasks in larger chunks.
You don't have to give up Atom, you can use Vim bindings in atom. Most editors support it to some extent via plugins.
I use vim bindings in Visual Studio, and I combine it with Resharper, and that is insanely awesome. I started writing a guide to it ( https://github.com/keithn/vsvimguide ) but it needs a bunch of work, I keep changing my mind about what the best starting bindings are to get the best blend of VS + R# and Vim ( I mainly fully embrace the Vim way, but I think thats too much when starting, it's best to start with the core Vim moving/editing and then learn to customize). But I digress, the "Changing Text" section has a number of combos that people often find a selling point of using Vim.
You don't have to give up Atom, you can use Vim bindings in atom. Most editors support it to some extent via plugins.
I use vim bindings in Visual Studio, and I combine it with Resharper, and that is insanely awesome. I started writing a guide to it ( https://github.com/keithn/vsvimguide ) but it needs a bunch of work, I keep changing my mind about what the best starting bindings are to get the best blend of VS + R# and Vim ( I mainly fully embrace the Vim way, but I think thats too much when starting, it's best to start with the core Vim moving/editing and then learn to customize). But I digress, the "Changing Text" section has a number of combos that people often find a selling point of using Vim.
What has always sold me on Vim is the fact that you can "compose" key commands, and as a result, you effectively can build your own commands.
For example, the `d` key begins the `delete` action, the `i` key means `inner` (or `current`) and `w` means `word`. From that, you can deduce that `diw` deletes the current word.
I figured that command out myself, among many other ones, and that only works because of the composable nature of Vim's modal editing.
Vim's macro system is also rather amazing, IMO. I haven't used Atom much, so I don't know if it's comparable, but I will usually set up several macros and compose them together to do mass edits of things.
For example, the `d` key begins the `delete` action, the `i` key means `inner` (or `current`) and `w` means `word`. From that, you can deduce that `diw` deletes the current word.
I figured that command out myself, among many other ones, and that only works because of the composable nature of Vim's modal editing.
Vim's macro system is also rather amazing, IMO. I haven't used Atom much, so I don't know if it's comparable, but I will usually set up several macros and compose them together to do mass edits of things.
Honestly though, is it even worth learning?
I've tried learning VIM a few times and always gave up, and feel like my editors shortcuts cover most cases anyway. There's also not that many times where I feel like coding speed is required. Honestly curious how much more productive you guys feel after learning VIM.
I've tried learning VIM a few times and always gave up, and feel like my editors shortcuts cover most cases anyway. There's also not that many times where I feel like coding speed is required. Honestly curious how much more productive you guys feel after learning VIM.
Personally, I would say it's probably not worth learning for most people. And I say this as a huge fan and many-year user of vim. I'll tell you why I like vim, and you can see if it resonates with you, and if not that's totally valid IMO.
The reason I use and like vim isn't because it improves my productivity. I mean, there's a chance it does, but I kinda doubt it makes that big a difference.
The reason I use vim is because I enjoy using it way more than any other editor. That's because with vim, the amount of time between me deciding on a specific change to make, to it happening, is almost instantaneous. In other editors, I have to spend time moving the cursor around, selecting stuff, etc. In vim, there's usually a command to get what I want done immediately. Not to mention that, with additional plugins, you can get some insane functionality that doesn't exist elsewhere (and you can easily customize vim to add commands that are relevant for you).
I don't think this impacts productivity, but it just makes vim more fun. And (in all seriousness), it's ruined me for other IDEs and editors. Even though there's a chance I'd be more productive in e.g. PyCharm, I can't make the switch because I'd miss too many things from vim.
Btw, it took me a long time to get semi-descent in vim, as I assume it takes most people. I did it not just because vim was a better editor and I was hooked, but because I enjoy playing with and customizing editors. So the amount of time I wasted (and still waste) on vim was enjoyable, so it was worth it to me. I wouldn't consider it productive time well spent though.
The reason I use and like vim isn't because it improves my productivity. I mean, there's a chance it does, but I kinda doubt it makes that big a difference.
The reason I use vim is because I enjoy using it way more than any other editor. That's because with vim, the amount of time between me deciding on a specific change to make, to it happening, is almost instantaneous. In other editors, I have to spend time moving the cursor around, selecting stuff, etc. In vim, there's usually a command to get what I want done immediately. Not to mention that, with additional plugins, you can get some insane functionality that doesn't exist elsewhere (and you can easily customize vim to add commands that are relevant for you).
I don't think this impacts productivity, but it just makes vim more fun. And (in all seriousness), it's ruined me for other IDEs and editors. Even though there's a chance I'd be more productive in e.g. PyCharm, I can't make the switch because I'd miss too many things from vim.
Btw, it took me a long time to get semi-descent in vim, as I assume it takes most people. I did it not just because vim was a better editor and I was hooked, but because I enjoy playing with and customizing editors. So the amount of time I wasted (and still waste) on vim was enjoyable, so it was worth it to me. I wouldn't consider it productive time well spent though.
For me the productivity boost is mostly a matter of having a suite of very powerful shortcuts/commands that I can use everywhere. I use them in all IDE's (IntelliJ, Visual Studio, Eclipse all have great vim plugins); I use them in any terminal I get access to, even when I can't install software; and I use them in less, Chrome, man and other other tools that copy vim's shortcuts either natively or through plugins.
In actual day to day use, it is more a matter of saving my fingers from stressful yoga tricks.
In actual day to day use, it is more a matter of saving my fingers from stressful yoga tricks.
+1
Also consider vim in your web browser (vimperator or vimfx or qutebrowser or vimium)
Vim in your file explorer (vifm)
Vim in your terminal (tmux in vim-mode)
Vim in your mayonnaise for lunch (https://lisalynnfit.vimtoday.com/images/thumbs/0000878_1200....)
Vim as a floor wax/desert topping (http://www.mysavings.com/img/link/large/74808.jpg)
and so forth.
Also consider vim in your web browser (vimperator or vimfx or qutebrowser or vimium)
Vim in your file explorer (vifm)
Vim in your terminal (tmux in vim-mode)
Vim in your mayonnaise for lunch (https://lisalynnfit.vimtoday.com/images/thumbs/0000878_1200....)
Vim as a floor wax/desert topping (http://www.mysavings.com/img/link/large/74808.jpg)
and so forth.
You mentioned tmux... What is the best counterpart windows solution by you? vim+tmux is awesome.
I really like the sound of this, and it's one of the reasons I've persisted with learning vim. But I have to admit, I have remapped a fair amount of stuff, so I'm not sure if it would apply to me.
Do those vim-mode plugins allow you to remap keys or load your vimrc?
I would say it's definitely worth learning, even if you don't use it for coding, simply for the reason that it's ubiquitous.
I use it constantly when configuring Linux machines, which is only an ancillary part of my job, just for the regex search to find the line I want to tweak. Since servers don't generally offer a GUI, it's the simplest way to replicate that feature.
I use it constantly when configuring Linux machines, which is only an ancillary part of my job, just for the regex search to find the line I want to tweak. Since servers don't generally offer a GUI, it's the simplest way to replicate that feature.
I have been using Vim for 15 years now and I see no other editor (not even Emacs) that comes anywhere close to the ergonomics of Vim. I can edit code the fastest in Vim.
If you think Vim is not helping you being more productive, I suggest reading the excellent StackOverflow answer that explains how learning Vim is like learning a language (not just learning keyboard shortcuts): https://stackoverflow.com/a/1220118/1175080
The only things that I find lacking in Vim is good support for various software development environments, for example, Java development. Another thing that used to bother me is the awkward placement of the Escape key but I overcome that easily by remapping my Caps Lock to Escape (see https://github.com/susam/uncap#uncap for examples).
If you think Vim is not helping you being more productive, I suggest reading the excellent StackOverflow answer that explains how learning Vim is like learning a language (not just learning keyboard shortcuts): https://stackoverflow.com/a/1220118/1175080
The only things that I find lacking in Vim is good support for various software development environments, for example, Java development. Another thing that used to bother me is the awkward placement of the Escape key but I overcome that easily by remapping my Caps Lock to Escape (see https://github.com/susam/uncap#uncap for examples).
No.
If you could improve your typing efficiency by an order of magnitude (not likely), how much time would you save? Minutes per day? Certainly not a whole hour.
Use a modern IDE with sane out-of-the-box configuration (ex: JetBrains.) Realize that you spend more time thinking than typing. Eliminate redundant typing with templates.
I used vi for years, then emacs for nearly two decades. I will never go back.
If you could improve your typing efficiency by an order of magnitude (not likely), how much time would you save? Minutes per day? Certainly not a whole hour.
Use a modern IDE with sane out-of-the-box configuration (ex: JetBrains.) Realize that you spend more time thinking than typing. Eliminate redundant typing with templates.
I used vi for years, then emacs for nearly two decades. I will never go back.
Although learning Vim gives you a productive editing environment, another advantage can be health related.
I find it more comfortable to have my fingers on the home row, than stretching them to pull off CTRL key-sequences.
I find it more comfortable to have my fingers on the home row, than stretching them to pull off CTRL key-sequences.
Thanks for making this tutorial and helping more people with Vim! I actually started learning Vim a few months ago. And to help me practice, a friend of mine recommended Vimgolf challenges. Since then I’ve been making weekly videos about the solutions to those challenges. I started it because some of the solutions were really hard to understand and I had almost given up a few times. I hope that by making videos it’ll help people see and understand some of the more complicated vim commands. I thought this would be a good place to share, hope it helps someone!
https://www.youtube.com/channel/UC9xP5LRmm2qbSKq6nHTB_bw?vie...
https://www.youtube.com/channel/UC9xP5LRmm2qbSKq6nHTB_bw?vie...
Here's a plug for bash with vim on the command line. (Ubuntu but also wsl). In your login dir, in .inputrc, add:
set editing-mode vi set keymap vi-command:w
This gives you vim on the command line, very handy.
Interactively, set -o vi will work.
This is a great way to 'live in vim.'
set editing-mode vi set keymap vi-command:w
This gives you vim on the command line, very handy.
Interactively, set -o vi will work.
This is a great way to 'live in vim.'
I apologize that this question is slightly tangential to the submitted post, but this seems like an ideal venue to ask: Is there a GUI interface to vim that has smooth-scrolling?
I've tried Gvim, but this just seems like vim with buttons (no smooth-scroll). I've tried Sublime text with the ActualVim plugin (powered by NeoVim), but this had errors which somehow swapped document buffers on write, essentially deleting an entire document (thankfully I had a backup).
I've tried Gvim, but this just seems like vim with buttons (no smooth-scroll). I've tried Sublime text with the ActualVim plugin (powered by NeoVim), but this had errors which somehow swapped document buffers on write, essentially deleting an entire document (thankfully I had a backup).
Spacemacs [0] :)
http://spacemacs.org/
http://spacemacs.org/
I haven't used it but there is https://github.com/terryma/vim-smooth-scroll
For GUIs, I tried VimR and MacVim. Neither seems to smooth-scroll. Using the above plugin might work though?
Also, have you tried Vintageous for Sublime Text? I use it and it works well.
For GUIs, I tried VimR and MacVim. Neither seems to smooth-scroll. Using the above plugin might work though?
Also, have you tried Vintageous for Sublime Text? I use it and it works well.
Do you mean scrolling with a mouse? It might sound a bit arrogant, but there's rarely any good reason to scroll with a mouse in vim.
Perhaps with a mouse, but not necessarily. I don't think your statement re: mouse scrolling applies universally. For programming script documents, sure -- each line is likely limited to the 80 column mark, and so the lines are quite short.
However, with Latex documents, for example, very long lines (i.e., paragraphs) are a big pain for me (even with vimrc options `set display=lastline` and `set linebreak`). In typical GUI text editors, the wrapped lines of long lines are treated as sort of "pseudo lines" themselves. This means when I cursor down (via mouse or keys), the cursor doesn't jump to the next newline after the paragraph (as it does with vim).
Apparently, this last described problem can be addressed [1]. So maybe the solution is that I need to spend more quality time with my vimrc? :)
[1]: http://vim.wikia.com/wiki/Move_cursor_by_display_lines_when_...
However, with Latex documents, for example, very long lines (i.e., paragraphs) are a big pain for me (even with vimrc options `set display=lastline` and `set linebreak`). In typical GUI text editors, the wrapped lines of long lines are treated as sort of "pseudo lines" themselves. This means when I cursor down (via mouse or keys), the cursor doesn't jump to the next newline after the paragraph (as it does with vim).
Apparently, this last described problem can be addressed [1]. So maybe the solution is that I need to spend more quality time with my vimrc? :)
[1]: http://vim.wikia.com/wiki/Move_cursor_by_display_lines_when_...
I would like to second this, and support you in that I don’t think it is an arrogant sentiment. Many of the efficiency gains vim gives you are the result of being able to navigate anywhere in a document or on a line with a few keystrokes. The mouse is comparatively slower, once the navigation commands are familiar.
I disagree, in only that good mouse support can help ease the transition and in some cases it may simply come down to user preference for some things. I don’t think personally that any text editor should be overly opinionated in how a user interacts with it; too much at least. I do agree that it is mostly more effective to not use a mouse once you know the commands
I think they're talking about animating scroll changes. Web browsers do this, if you press page down, it animates the change(it's subtle, the animation only lasts a fraction of a second).
In Vim, it'll just do an instant repaint, so you kind of lose context.
In Vim, it'll just do an instant repaint, so you kind of lose context.
I've tried learning Vim several times, but the need to switch modes and back for cursor movement has been a huge turnoff, especially considering the location of the ESC key. It seems to just conflict with the way that I type, where I am frequently jumping my cursor around in the middle of text editing, which is effortless in Emacs. Maybe mastering Vim is not just about memorizing key combos but about changing your coding workflow?
Mastering vim is about learning a language (of verbs and objects) for communicating effectively with your text editor.
The modal aspects are there, but my experience has been that 80% of my editing time is spent reading and finding the right place to put something, and the default when opening a file is reading to find the right spot. Further, switching from read mode to write mode is often done with different purposes, and vim lets me express those different intents when changing modes (insert here, replace this word, replace this line, etc).
I think there is probably a little bit of changing your workflow, but for me it's been largely about learning how vim fits my workflow.
The modal aspects are there, but my experience has been that 80% of my editing time is spent reading and finding the right place to put something, and the default when opening a file is reading to find the right spot. Further, switching from read mode to write mode is often done with different purposes, and vim lets me express those different intents when changing modes (insert here, replace this word, replace this line, etc).
I think there is probably a little bit of changing your workflow, but for me it's been largely about learning how vim fits my workflow.
> especially considering the location of the ESC key
This can be solved by remapping ESC to Capslock.
This can be solved by remapping ESC to Capslock.
Exactly. Or remap it to any key combination that makes sense for your work, if you like using Capslock for its original purpose, which I happen to.
For example, I have jj and jk mapped to ESC. So I just tap j twice while in insert mode, and it switches to normal/command mode. If you find yourself needing to type jj or jk often in insert mode, just pick other letters that make sense for you.
To use mine, plop these in your .vimrc:
For example, I have jj and jk mapped to ESC. So I just tap j twice while in insert mode, and it switches to normal/command mode. If you find yourself needing to type jj or jk often in insert mode, just pick other letters that make sense for you.
To use mine, plop these in your .vimrc:
inoremap jj <Esc>
inoremap jJ <Esc>
inoremap jk <Esc>I do it with zz, which I find is consistent with ZZ (save and quit).
You can also remap it to multiple keys. My preference is `jk`, since that letter combination is rarely used, still on home row, and can be typed about as fast as a single key. Useful, since it's a common action I take.
I go for jj since it removes the mental overhead. Often I'm just pawing through the code from top to bottom and in either normal or insert mode I just start hammering at jj and I start moving.
Or mapping ctrl to capslock and using C-[ for escape.
I feel the same way. vim is optimized for editing text rather than writing new text. The assumption is that we are editing existing text more often than writing new text when coding.
I don't even remember how to do this common things, if not in vim. How do you swap two lines? Something like "Home", "Shift+End", Ctrl +X", "Up", "Ctrl + V"? Or with the mouse?
I'm assuming you're jumping the cursor around to get to a different location in the text to make an edit? I use / (search forward) and ? (search backwards) a lot. It means that when you think to yourself "I need to edit XYZ" the command is, jump to XYZ, instead of down-across
-across etc.
No doubt, becoming proficient in vim is a big commitment that you really have to work at. Personally I think it's a great editor though.
No doubt, becoming proficient in vim is a big commitment that you really have to work at. Personally I think it's a great editor though.
Try Ctrl-C which is equivalent to ESC in vim.
The single thing you need to do to learn vim is to download the ViEmu cheatsheet[0], print it out, and stick it on the wall where you can see it. Printing it out is mandatory - you need to be able to see it without switching windows.
Putting things up on the wall is like a free, albeit static, extra monitor. :-)
[0] http://www.viemu.com/vi-vim-cheat-sheet.gif
Putting things up on the wall is like a free, albeit static, extra monitor. :-)
[0] http://www.viemu.com/vi-vim-cheat-sheet.gif
To learn Vim you have to use it everyday. Question is if most have the opportunity to use it full-time for development from day one. I started with Vim using it just as a todo list manager on a remote server. Wrote here and there some macros to add or mark todos and that was my gateway drug. Used it everyday and at some point it felt more natural than any other editor. So I fully switched.
Besides, I use Neovim for 1-2 years now.
Besides, I use Neovim for 1-2 years now.
I 100% agree. I originally learnt Vim because I didn't have any choice. It was the only supported editor at my workplace, so I was thrown in the deep end, using it every day.
That kind of situation can foster resentment, but I embraced the challenge. I got use to Vim, and overall adopted a more "UNIX" approach to my workflow and development. I'm not all the way there, but I'm trying to embrace it more, little by little.
That kind of situation can foster resentment, but I embraced the challenge. I got use to Vim, and overall adopted a more "UNIX" approach to my workflow and development. I'm not all the way there, but I'm trying to embrace it more, little by little.
To make the basic vim movement keys (hjkl) second nature to you, play games that use them for movement, like Nethack[1] and Dungeon Crawl Stone Soup.[2]
[1] - http://www.nethack.org/
[2] - https://crawl.develz.org/
[1] - http://www.nethack.org/
[2] - https://crawl.develz.org/
Coincidentally we've recently shipped a tutorial for Nano except we've decided to build it strait into our editor! After you 'sudo apt update && sudo apt upgrade && sudo apt install nano' you can run 'nano' in your terminal. At the bottom of your terminal window you'll see a set of hand-picked lessons displayed for you. Anywhere you see "^" you just hold CNTRL on your keyboard. Unfortunately we didn't have the funds to implement our own content in the tutorial series. You'll have to provide your own textual media to practice on. You can do this by typing "nano <your_file_name>" in the terminal which will launch our tutorial system with your file. The tutorial system is very unobtrusive and will remain on the bottom of your screen until you add 'set nohelp' to your nanorc.
Are there any common "home row arrow key" schemes besides the Vim HJKL? Need to determine which to learn, and those 4 have never made sense to me.
ESDF and IJKL look temping
Typing in Dvorak, I'd need to remap anyway before being able to use the keys. May as well pick the best scheme.
ESDF and IJKL look temping
Typing in Dvorak, I'd need to remap anyway before being able to use the keys. May as well pick the best scheme.
It would be amazing to be able to play with the commands in addition to pressing exactly the keys that the tutorial tells you to press.
Get a demonstration, then try on your own.
Or maybe even include a vim golf game as an exercise? E.g. get to some word in less than four key presses.
Get a demonstration, then try on your own.
Or maybe even include a vim golf game as an exercise? E.g. get to some word in less than four key presses.
vim golf needs to be multiplayer
Is there something similar to this for emacs?
To expand on the answers, C-h t opens the built in tutorial, which is good. It only covers the basics of navigation, but that's what you need to know to start. The tutorial is interactive.
Since emacs changes its behavior depending on the mode, it would be impractical to do a more in depth tutorial, in my opinion, but I liked the Mastering Emacs ebook.
Since emacs changes its behavior depending on the mode, it would be impractical to do a more in depth tutorial, in my opinion, but I liked the Mastering Emacs ebook.
One of the very best features of Emacs is it's built in help system, faster, more convenient and more accurate than most program wikis or on-line documentation.
Emacs is too big to learn every one of the 7000 or so functions, one learns just what's useful in a particular realm. Anytime it's necessary to wander into new territory, there is really good built-in help system available. Help commands start with Ctrl-h. The next keystroke determines the kind of help that comes next.
A handy prompt after Ctrl-h suggests typing '?' for additional options. The basics options are:
a PATTERN -- show commands whose name matches PATTERN
d PATTERN -- show commands whose documentation has a match to PATTERN
f -- documentation of a particular function
c -- what command runs for a particular Emacs key sequence
t -- learn by doing tutorial.
There is a full page of other help options including access to the full emacs manual.
Emacs is too big to learn every one of the 7000 or so functions, one learns just what's useful in a particular realm. Anytime it's necessary to wander into new territory, there is really good built-in help system available. Help commands start with Ctrl-h. The next keystroke determines the kind of help that comes next.
A handy prompt after Ctrl-h suggests typing '?' for additional options. The basics options are:
a PATTERN -- show commands whose name matches PATTERN
d PATTERN -- show commands whose documentation has a match to PATTERN
f -- documentation of a particular function
c -- what command runs for a particular Emacs key sequence
t -- learn by doing tutorial.
There is a full page of other help options including access to the full emacs manual.
The only gripe I have with emacs help, is that it does require some basic skill to use it. The help opens in a window in the existing frame and you need to know how to jump back and forth and close. It's a bit like having to drive yourself to your learning to drive lessons. But once you've done the built in tutorial a few times, you should have that basic skill.
> The only gripe I have with emacs help, is that it does require some basic skill to use it.
The only thing to know is to press 'q' to quit the help window and get back to where you were.
The only thing to know is to press 'q' to quit the help window and get back to where you were.
Some say "Ctrl-h t" is the vimtutor of emacs...
ctrl-h t
The emacs tutorial: ”Just type shit. Seriously. It’s a text editor. It works like you think it should. No autistic screeching required to enable edit mode to actually, you know, edit fucking text in a fucking text editor.”
Do you know the command to quit vim?
CTRL-Z
sudo killall vim
sudo apt uninstall vim
Do you know the command to quit vim?
CTRL-Z
sudo killall vim
sudo apt uninstall vim
Good heavens, you've managed to imbue a classic editor flamewar comment with a surprising extra dose of incivility. This violates the guidelines, so please don't post like this again.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
I was just watching my daughter writing a program in Java using eclipse. It's frustrating to watch a relative beginner editing using a combination of the mouse and the keyboard--it's so slow.
Kind of off-topic but this is probably a decent place to ask..
I've just started working on a text editor as a side project, and one of the main things I want to include is a really complete implementation of vim keybindings. So far I just have a queue of keyboard events. Basic movements seem pretty easy, but I'm worried about operator motions (d6w - delete 6 words, etc). Will I basically need to build a parser?
Any guidance or keywords I can use to research/learn how to do this would be greatly appreciated.
I've just started working on a text editor as a side project, and one of the main things I want to include is a really complete implementation of vim keybindings. So far I just have a queue of keyboard events. Basic movements seem pretty easy, but I'm worried about operator motions (d6w - delete 6 words, etc). Will I basically need to build a parser?
Any guidance or keywords I can use to research/learn how to do this would be greatly appreciated.
I would like to read a long and interesting article like this, but for emacs, because I've been mainly a vi/vim guy (on both Unix and Windows) (plus use of various other text editors on Windows (Textpad, Notepad++, Metapad (light use, like a better Notepad), PFE (older, cool one, it could edit really large files), Norton Editor (NE, damn fast one), and some others, but interested in learning about emacs' capabilities.
A little off-topic, but if you like working in Vim, try using cVim[1] for Chrome. It really makes your browsing experience a lot faster, especially if you're on a laptop.
[1] https://chrome.google.com/webstore/detail/cvim/ihlenndgcmojh...
[1] https://chrome.google.com/webstore/detail/cvim/ihlenndgcmojh...
Is there anything better about this than vimium?
The most disappointing thing about using an extension for this is when I open dev tools or a tab fails to load. I love luakit because the browser itself lets you set up vim like commands. Unfortunately I had to give up trying to build it for macOS
The most disappointing thing about using an extension for this is when I open dev tools or a tab fails to load. I love luakit because the browser itself lets you set up vim like commands. Unfortunately I had to give up trying to build it for macOS
Vimium has been a very frustrating experience for me. The one thing where I always trip:
- Press 't' to open a new tab.
- Now I realize I want to go back to the previous tab. I press 'Escape'. Nothing happens. The focus is stuck in the address bar. I press 'J' and of course the 'J' gets typed into the address bar. How do I escape back to normal mode? I can't figure.
With VimFx for Firefox, it works exactly as one would imagine.
- Press 't' to open a new tab.
- Now I realize I want to go back to the previous tab. Press 'Escape' to return to normal mode. Press 'J' to go back to the previous tab.
If this is something that works fine in cVim, I am going to ditch Vimium in favor of cVim today!
- Press 't' to open a new tab.
- Now I realize I want to go back to the previous tab. I press 'Escape'. Nothing happens. The focus is stuck in the address bar. I press 'J' and of course the 'J' gets typed into the address bar. How do I escape back to normal mode? I can't figure.
With VimFx for Firefox, it works exactly as one would imagine.
- Press 't' to open a new tab.
- Now I realize I want to go back to the previous tab. Press 'Escape' to return to normal mode. Press 'J' to go back to the previous tab.
If this is something that works fine in cVim, I am going to ditch Vimium in favor of cVim today!
I tried pentadectyl for firefox and couldn't get it to work after 1 hour of messing around (some version issues). I'll try vimfx because I'm not too happy with cvim either mainly because it won't run on chrome:// pages which makes it necessary to use the mouse afterall.
yes i agree with you about not being able to use it in dev tools is super annoying. the author did mention a workaround for it in the reddit thread but it never worked for me.
[deleted]
Obligatory link to VimGolf, a great way to learn by doing.
https://vimgolf.com/
https://vimgolf.com/
This website sucks, it takes forever to load challenge pages because they're flooded with irrelevant entries which you can't even see if you don't submit your own. You can't even visualize the solutions directly in the browser.
And you never really get to learn anything. I generally come away feeling like there's this knowledge locked in solutions I'll never get to see so there's no way to improve. Seems like a good idea but in practice it's just frustrating.
Also Vim Adventures:
https://vim-adventures.com/
https://vim-adventures.com/
> Also Vim Adventures
On https://news.ycombinator.com/item?id=14658197 and its children I wrote something about the business model of VIM Adventures that you should consider before buying.
On https://news.ycombinator.com/item?id=14658197 and its children I wrote something about the business model of VIM Adventures that you should consider before buying.
The website needs a rework. Some challenges load more than 300mb of images.
Now I wonder if there's a js library which makes a textfield behave like VIM...
Guess I'll need to look at the source here later on to find out.
Guess I'll need to look at the source here later on to find out.
I know that ace editor[1] has key biding for vim. The chrome plugin SurfingKeys[2] use it internally.
[1] https://ace.c9.io/
[2] https://github.com/brookhong/Surfingkeys
[1] https://ace.c9.io/
[2] https://github.com/brookhong/Surfingkeys
Actually I've always wanted Microsoft Office and Outlook editors to behave like vim
since this site doesn't let you experiment, i'd guess they didn't actually emulate vim. it's little more than a slide deck triggered by specific keypresses.
Makes sense, vim emulation seems a bit overkill for this^^
Closest thing I can think of is CodeMirror: https://codemirror.net/demo/vim.html
Not to be that that guy but I’m gonna go ahead and plug spacemacs here. Using it in Vim (EVIL) mode I found it to be basically like vim navigationally speaking, plus they have a built completer for commands and you can even get help with commands in real time using ? And just start typing. Not a knock against Vim just something I found to be very beginner friendly
nnoremap h j
You should be able to put
(define-key evil-normal-state-map "h" 'evil-next-line)
That doesn't work everywhere. This was my dealbreaker with Spacemacs. To remap hjkl to jkl; (imperfectly at that) I had to do the following:
(define-key evil-normal-state-map (kbd "j") 'evil-backward-char)
(define-key evil-normal-state-map (kbd "k") 'evil-next-visual-line)
(define-key evil-normal-state-map (kbd "l") 'evil-previous-visual-line)
(define-key evil-normal-state-map (kbd ";") 'evil-forward-char)
(define-key evil-visual-state-map (kbd "j") 'evil-backward-char)
(define-key evil-visual-state-map (kbd "k") 'evil-next-line)
(define-key evil-visual-state-map (kbd "l") 'evil-previous-line)
(define-key evil-visual-state-map (kbd ";") 'evil-forward-char)
(define-key evil-motion-state-map (kbd "j") 'evil-backward-char)
(define-key evil-motion-state-map (kbd "k") 'evil-next-line)
(define-key evil-motion-state-map (kbd "l") 'evil-previous-line)
(define-key evil-motion-state-map (kbd ";") 'evil-forward-char)
(define-key dired-mode-map (kbd "j") 'evil-backward-char)
(define-key dired-mode-map (kbd "k") 'evil-next-line)
(define-key dired-mode-map (kbd "l") 'evil-previous-line)
(define-key dired-mode-map (kbd ";") 'evil-forward-char)) (defun multi-evil-define (d symb)
(define-key evil-normal-state-map d symb)
(define-key evil-motion-state-map d symb)
(define-key evil-visual-state-map d symb)
(define-key dired-mode-map d symb))
(multi-evil-define (kbd "j") 'evil-backward-char) ....So... many... commands.
So... much... power.
With great power comes great editability.
I wonder what was the issue with arrow keys. Were there keyboards that lacked them?
Yep, but it then stayed that way because arrow keys are distant and require you to leave the home row, while hjkl are on the home row.
Vim is all about ergonomic touch-typing.
Vim is all about ergonomic touch-typing.
the other answer is also correct but you are correct as well! The machine vim was developed on didn't have arrow keys but used hjkl for arrows:
http://www.catonmat.net/blog/why-vim-uses-hjkl-as-arrow-keys...
Just last week my team and I understood how to select inside and around of brackets.
vi" - select inside "
va{ - select around curly brackets
How is a web-based tutorial better than "the real thing" (i.e. vimtutor)?
I have to say how confusing I found this demo without a US keyboard. In section 10 I spent far too long pressing Shift+3 and wondering why it wouldn't progress even though I was pressing the pound key (£).
best way to learn vim:
(optional) first, go thru vimtutor (just type vimtutor in your shell and press enter).
second, get a vim cheat sheet (google).
finally (most important), code a few things using vim. keep google at the ready to look up "how do (etc)?" to speed up things you're actually doing.
once comfortable with that, maybe watch a few vim tips videos.
after all that, you will probably find vim much more comfortable than gedit, textedit, notepad, etc, just for the power. if you favor ides, you'll probably need to do a lot of tweaking to love raw vim, though or course some ides offer vim keymapping anyway.
(optional) first, go thru vimtutor (just type vimtutor in your shell and press enter).
second, get a vim cheat sheet (google).
finally (most important), code a few things using vim. keep google at the ready to look up "how do (etc)?" to speed up things you're actually doing.
once comfortable with that, maybe watch a few vim tips videos.
after all that, you will probably find vim much more comfortable than gedit, textedit, notepad, etc, just for the power. if you favor ides, you'll probably need to do a lot of tweaking to love raw vim, though or course some ides offer vim keymapping anyway.
I really liked having a "vim mug" as cheat sheet. If you drink hot liquids at your desk you'll have a mug anyway. This way it doubles as a vim reference while you're learning and you're probably less likely to lose it.
My biggest vim efficiency booster is remapping <esc> to "jk"
What do you do when you actually need to type the string "jk"? Type "j", then wait for sometime and then type "k"?
Wait, Shift+7 for slash? What keyboard layout is this? I had already noticed various other weird things about the layout depicted on the screen, but that one takes the cake.
Probably Spanish. It's a horrible layout for developers, curly braces involve alt-gr for instance...
As well as the German layout. But you get used to if you don't know anything else.
Looking at the TOC, its missing cut/copy and paste, which is pretty important for any text editor
It's true, but since vim is a bit old, copy/pasting can be a bit awkward due to having an internal clipboard with the buffer and not using the system's clipboard.
I wouldn't put that in a beginner tutorial (at least the system clipboard copying/pasting).
I wouldn't put that in a beginner tutorial (at least the system clipboard copying/pasting).
Vim has system clipboard support with the `+` and `*` registers.
Right. But what I was saying is that, I wouldn't throw that into a beginner's tutorial right away.
they are sprinkled around
cut: x,d,c,s
copy: y
paste: p
different variations for different use cases, can be combined with movement commands, can be repeated, etc
cut: x,d,c,s
copy: y
paste: p
different variations for different use cases, can be combined with movement commands, can be repeated, etc
[deleted]
The day I commit myself to learning vim properly, this comes up. Thanks for posting!
It's using hardcore classic vim key bindings. Insert mode doesn't even start when pressing actual Ins. I understand some can have nostalgia for the times of archaic terminals, but I find it counter productive. Sorry, but I'm going to use Ins and regular arrow keys, not i and h,j,k,l.
Then you’re missing the point of touch typing the commands from the home row.
I simply find those keys for navigation awkward and out of place. Habits play a role here.
It's hugely inefficient to have to pick up your hand every time you want to move the cursor (assuming you're a developer and spend a significant amount of time in a text editor). If you don't want to learn a new tool to improve efficiency that's one thing but saying that it's out of place to use the 'hjkl' keys for navigation is pretty misguided.
Efficient enough for me. And yes, for me those keys are out of place for navigation.
(Incoming controversial anti-Vim comment. Down voting because you disagree is a poor show and a poor argument. Convince me otherwise with words, good sirs and madams.)
Vim, beyond the very basics for server side administrative tasks, isn't worth your time.
Vim isn't worth the investment in time for me, as an average programmer, and I doubt it's worth the time of most other (average) developers as well. It's a big investment in retraining muscle memory and rethinking about how your editor works for, frankly, little gain.
"It speeds you up" - no it doesn't. It gives you access to keyboard shortcuts for moving around your buffer that other editors give you. It has a cool way of looking at text and once understood, you can do cool shit. I never could find a need for any of that stuff, even after spending a week or so learning it and adjusting muscle memory. After moving to VSCode, I've never missed that stuff neither. That says a lot about my personal use case I'll admit, but my use case in very common as an everyday programmer.
Funny enough, most editors have plugins to enable Vim modes and keyboard weirdness anyway.
So I've tried moving to Vim from Sublime, and I'm thankful for the time I invested, but I quickly realised that Vim (and Sublime, actually) fall short compared to VSCode or a serious IDEs. And yes, I'm aware you can make Vim behave like an IDE - I did it. I get it. It's not worth the time.
With modern, graphical editors and IDEs like VSCode, Atom, Eclipse, the IntelliJ family like IDEs, and so on, you get up and running straight away. You can extend them very quickly using a built in plugin system - you don't even have to leave the software.
I use VSCode, and I've found that I haven't had to leave the editor or install anything outside of VSCode plugins to make it operate as a Java IDE, Go IDE (OK, I had to install Delve), or Python IDE. It has saved me a lot of time tinkering and allowed me to just get going. It even PROMPTED me when I opened a Python, Go, or JavaScript file for the first and offered to install plugins for making the file easier to work with... YES PLEASE! And yes I know Vim can do these things (using external, third party plugins.) I did it. I get it. It's not worth the time.
I'm also aware that Vim uses kilobytes, perhaps megabytes, of RAM to operate and VSCode uses hundreds. And that's a problem how? I have 16GB of RAM on a system running a single VM for Docker and a browser. I'm the first person you'll find who will complain about how bloated and heavy applications are in this day and age, believing that us programmers are getting lazy due to an ever increase in resources, but a few hundred MBs of RAM for massive time savings and a great UI is worth it.
It's simply not worth the time invested. The basics allow you to do quick server side stuff and you'll be thankful for the knowledge, but beyond that use something designed for the job, even if it does eat RAM for breakfast.
Vim, beyond the very basics for server side administrative tasks, isn't worth your time.
Vim isn't worth the investment in time for me, as an average programmer, and I doubt it's worth the time of most other (average) developers as well. It's a big investment in retraining muscle memory and rethinking about how your editor works for, frankly, little gain.
"It speeds you up" - no it doesn't. It gives you access to keyboard shortcuts for moving around your buffer that other editors give you. It has a cool way of looking at text and once understood, you can do cool shit. I never could find a need for any of that stuff, even after spending a week or so learning it and adjusting muscle memory. After moving to VSCode, I've never missed that stuff neither. That says a lot about my personal use case I'll admit, but my use case in very common as an everyday programmer.
Funny enough, most editors have plugins to enable Vim modes and keyboard weirdness anyway.
So I've tried moving to Vim from Sublime, and I'm thankful for the time I invested, but I quickly realised that Vim (and Sublime, actually) fall short compared to VSCode or a serious IDEs. And yes, I'm aware you can make Vim behave like an IDE - I did it. I get it. It's not worth the time.
With modern, graphical editors and IDEs like VSCode, Atom, Eclipse, the IntelliJ family like IDEs, and so on, you get up and running straight away. You can extend them very quickly using a built in plugin system - you don't even have to leave the software.
I use VSCode, and I've found that I haven't had to leave the editor or install anything outside of VSCode plugins to make it operate as a Java IDE, Go IDE (OK, I had to install Delve), or Python IDE. It has saved me a lot of time tinkering and allowed me to just get going. It even PROMPTED me when I opened a Python, Go, or JavaScript file for the first and offered to install plugins for making the file easier to work with... YES PLEASE! And yes I know Vim can do these things (using external, third party plugins.) I did it. I get it. It's not worth the time.
I'm also aware that Vim uses kilobytes, perhaps megabytes, of RAM to operate and VSCode uses hundreds. And that's a problem how? I have 16GB of RAM on a system running a single VM for Docker and a browser. I'm the first person you'll find who will complain about how bloated and heavy applications are in this day and age, believing that us programmers are getting lazy due to an ever increase in resources, but a few hundred MBs of RAM for massive time savings and a great UI is worth it.
It's simply not worth the time invested. The basics allow you to do quick server side stuff and you'll be thankful for the knowledge, but beyond that use something designed for the job, even if it does eat RAM for breakfast.
Aside from the other comments, you're missing a huge part of what vim is about if you think that it's vim vs. every other IDE. I use IDE's but I use a vim plugin in every single one to enable the vim key binding so I can enjoy all the IDE has to offer AND vim at the same time. It's not just about the editor itself (which I will talk more about), it's about the editing paradigm it introduces. A paradigm that emphasizes programming efficiency over familiarity. I understand that trade off isn't for everyone though.
In contrast to what I just wrote, the ubiquitous nature of vim is a huge factor for anyone who does a lot of work on a number of remote servers where it's not feasible to use a GUI-based IDE. You can use nano if you really don't want to learn vim but I'd love to hear someone make a case for using nano over vim. You may only need to deal with this for 'basic server side administration tasks' but a lot of people have to do a significant amount of work on multiple servers due to data access and resource availability issues.
In addition, there is also the fact that a number of command line tools use vim key bindings for navigation (eg. man, less, more)
*Edit: grammar
In contrast to what I just wrote, the ubiquitous nature of vim is a huge factor for anyone who does a lot of work on a number of remote servers where it's not feasible to use a GUI-based IDE. You can use nano if you really don't want to learn vim but I'd love to hear someone make a case for using nano over vim. You may only need to deal with this for 'basic server side administration tasks' but a lot of people have to do a significant amount of work on multiple servers due to data access and resource availability issues.
In addition, there is also the fact that a number of command line tools use vim key bindings for navigation (eg. man, less, more)
*Edit: grammar
> It gives you access to keyboard shortcuts for moving around ...
Your whole comment can be dismissed easily because of this one gross misunderstanding. Vim is not a bunch of weird keyboard shortcuts. If one approaches Vim as an editor that uses keyboard shortcuts that are inconsistent with every other editor out there, then one is simply setting themselves up for pain and unproductivity.
Vim is not a bunch of keyboard shortcuts. It is an interactive editing language! For more, see this excellent comment on StackOverflow: https://stackoverflow.com/a/1220118/1175080 (a very well written answer!).
Your whole comment can be dismissed easily because of this one gross misunderstanding. Vim is not a bunch of weird keyboard shortcuts. If one approaches Vim as an editor that uses keyboard shortcuts that are inconsistent with every other editor out there, then one is simply setting themselves up for pain and unproductivity.
Vim is not a bunch of keyboard shortcuts. It is an interactive editing language! For more, see this excellent comment on StackOverflow: https://stackoverflow.com/a/1220118/1175080 (a very well written answer!).
It's an interactive editing language... that I'll never use and still be as productive as you.
No, you won't be as productive as me.
The fact that you were not aware how Vim is different than other editor (editing language vs. keyboard shortcuts) shows that you use your current editor as a macro for keyboard shortcuts rather than something you can talk to with little verbs and nouns and combine them into complex editing instructions with ease.
There is no way you can match my speed and productivity of editing and refactoring code with that kind of approach to editors.
The fact that you were not aware how Vim is different than other editor (editing language vs. keyboard shortcuts) shows that you use your current editor as a macro for keyboard shortcuts rather than something you can talk to with little verbs and nouns and combine them into complex editing instructions with ease.
There is no way you can match my speed and productivity of editing and refactoring code with that kind of approach to editors.
I'm happy you like VSCode so much. I do too, but I don't think it really qualify as a IDE. Same goes for Atom. Unless you consider Sublime an IDE as well. It has all the features they do, mainly because they ripped it off to gain them.
Putting that aside, I totally understand what you're saying about Vim. I felt the same way when I started out with it. But I didn't have a choice at the time because the company I work at only supported Vim, and there weren't too many other options around at the time. Atom was just new and ran like a dog. We were told we couldn't use Sublime unless we bought a license, so I was stuck with Vim.
And now, after 3 years of learning, and tweaking, and practising, I get Vim. I'm not a hardcore user; I don't use hjkl, I rarely use any register apart from ", but that doesn't mean I'm not getting any benefit from Vim. There are definitely some features in those other editors that are also attractive, but I've managed to find ways to replicate them in Vim, either using plugins or by mapping commands.
That said, at home I still use Sublime, but it has been pretty awkward because my hands are so use to certain Vim things, that I find myself pressing keys, doing things I didn't intend a lot. Installing a Vim-mode plugin to one of those editors doesn't fix that.
Putting that aside, I totally understand what you're saying about Vim. I felt the same way when I started out with it. But I didn't have a choice at the time because the company I work at only supported Vim, and there weren't too many other options around at the time. Atom was just new and ran like a dog. We were told we couldn't use Sublime unless we bought a license, so I was stuck with Vim.
And now, after 3 years of learning, and tweaking, and practising, I get Vim. I'm not a hardcore user; I don't use hjkl, I rarely use any register apart from ", but that doesn't mean I'm not getting any benefit from Vim. There are definitely some features in those other editors that are also attractive, but I've managed to find ways to replicate them in Vim, either using plugins or by mapping commands.
That said, at home I still use Sublime, but it has been pretty awkward because my hands are so use to certain Vim things, that I find myself pressing keys, doing things I didn't intend a lot. Installing a Vim-mode plugin to one of those editors doesn't fix that.
> I'm happy you like VSCode so much. I do too, but I don't think it really qualify as a IDE. Same goes for Atom. Unless you consider Sublime an IDE as well. It has all the features they do, mainly because they ripped it off to gain them.
I never said it was an IDE. At least, I never intended to say it was, because it's not.
> And now, after 3 years of learning, and tweaking, and practising, I get Vim.
It took three years to learn to use Vim to be productive, is what you're saying here. Point and case.
I never said it was an IDE. At least, I never intended to say it was, because it's not.
> And now, after 3 years of learning, and tweaking, and practising, I get Vim.
It took three years to learn to use Vim to be productive, is what you're saying here. Point and case.
> It took three years to learn to use Vim to be productive, is what you're saying here. Point and case.
It didn't take three years to get productive. It probably took a few months before I was fully productive, and that was while learning a new language and new codebase at the same time.
It's taken 3 years to get, not just comfortable and familiar but, beyond comfortable with Vim. It's taken 3 years for Vimming to become second nature. Actually, that's not true. I was typing Vim commands into my browser at the start of the year, so it's probably more like two years.
And that's not even 100% solid use. Last year, I used a lot of IntelliJ, VSCode, and Eclipse, but using Vim 1-2 days a week kept me in the habit enough that it's second nature to me.
It didn't take three years to get productive. It probably took a few months before I was fully productive, and that was while learning a new language and new codebase at the same time.
It's taken 3 years to get, not just comfortable and familiar but, beyond comfortable with Vim. It's taken 3 years for Vimming to become second nature. Actually, that's not true. I was typing Vim commands into my browser at the start of the year, so it's probably more like two years.
And that's not even 100% solid use. Last year, I used a lot of IntelliJ, VSCode, and Eclipse, but using Vim 1-2 days a week kept me in the habit enough that it's second nature to me.
Fair enough!
I'm honestly glad it's working for you. The point of my original post was to talk to new users of Vim. You're quite well established with Vim so it's easy to have the opinion that it's not too difficult to use. However, I believe there are better options that enable people to be just as productive in a fraction, of a fraction of the time.
Good luck.
I'm honestly glad it's working for you. The point of my original post was to talk to new users of Vim. You're quite well established with Vim so it's easy to have the opinion that it's not too difficult to use. However, I believe there are better options that enable people to be just as productive in a fraction, of a fraction of the time.
Good luck.
I mentioned this in another comment but it's worth reiterating: IDE's and vim are not mutually exclusive. Every IDE offers a vim mode or vim plugin that gives you the best of both worlds.
> I use VSCode, and I've found that I haven't had to leave the editor or install anything outside of VSCode plugins to make it operate as a Java IDE, Go IDE (OK, I had to install Delve), or Python IDE.
You explicitly called it an IDE.
> It took three years to learn to use Vim to be productive, is what you're saying here. Point and case.
They didn't say that. Anyone without sever learning difficulties should be as productive in vim as any text editor in a few days at most, it just takes years to master because it's capable of so much.
You explicitly called it an IDE.
> It took three years to learn to use Vim to be productive, is what you're saying here. Point and case.
They didn't say that. Anyone without sever learning difficulties should be as productive in vim as any text editor in a few days at most, it just takes years to master because it's capable of so much.
> You explicitly called it an IDE.
I called it an editor that I made into an IDE. It operates no different than the most powerful IDEs available for the languages listed.
> Anyone without sever learning difficulties
Now you're just being rude.
I called it an editor that I made into an IDE. It operates no different than the most powerful IDEs available for the languages listed.
> Anyone without sever learning difficulties
Now you're just being rude.
I learned vim on Ubuntu 8.04 by using vimtutor.
unbelievable, it's so much fun.
That was fun.
The first thing I do on a new system is map my Caps Lock key to Escape[1][2][3] so that I can use Vim conveniently without having to reach the physical Escape key placed awkwardly at the corner of the keyboard.
The choice of Escape key to return to normal mode and H, J, K, L for navigation makes total sense if we look at the original Lear Siegler ADM-3A terminal[4] that Bill Joy used while creating vi, but in the modern day keyboard, the choice of Escape key to return to normal mode really disturbs the otherwise fine ergonomics of using Vim.
[1]: https://github.com/susam/uncap#uncap
[2]: http://vim.wikia.com/wiki/Map_caps_lock_to_escape_in_Windows...
[3]: http://vim.wikia.com/wiki/Map_caps_lock_to_escape_in_XWindow...
[4]: https://vintagecomputer.ca/wp-content/uploads/2015/01/LSI-AD...
The choice of Escape key to return to normal mode and H, J, K, L for navigation makes total sense if we look at the original Lear Siegler ADM-3A terminal[4] that Bill Joy used while creating vi, but in the modern day keyboard, the choice of Escape key to return to normal mode really disturbs the otherwise fine ergonomics of using Vim.
[1]: https://github.com/susam/uncap#uncap
[2]: http://vim.wikia.com/wiki/Map_caps_lock_to_escape_in_Windows...
[3]: http://vim.wikia.com/wiki/Map_caps_lock_to_escape_in_XWindow...
[4]: https://vintagecomputer.ca/wp-content/uploads/2015/01/LSI-AD...
Mapping jk and kj to escape and mapping caps lock to some other hyper key is way better than caps lock to esc IMO. You can just mash both j and k together and you are out of it.
inoremap jk <esc>
And
inoremap kj <esc>
In your vimrc file should do it.
inoremap jk <esc>
And
inoremap kj <esc>
In your vimrc file should do it.
I have considered such alternatives in the past and they did not work for me. For example, how can I conveniently type the string "jk" or "kj" with such a configuration?
The artificial delay I have to introduce between typing "j" and "k" to actually type "jk" is unacceptable. Although it is rare, I sometimes do have to type "jk" in special circumstances such as while typing LaTeX code.
Mapping Caps Lock to Escape is just a much cleaner solution that does not come with any surprises.
The artificial delay I have to introduce between typing "j" and "k" to actually type "jk" is unacceptable. Although it is rare, I sometimes do have to type "jk" in special circumstances such as while typing LaTeX code.
Mapping Caps Lock to Escape is just a much cleaner solution that does not come with any surprises.
Another approach is using 'jj'.
> The artificial delay I have to introduce between typing "j" and "k" to actually type "jk" is unacceptable.
I tried the CAPS approach and tried using it via my left pinky, but find it too awkward to use - but this is probably a very individual thing and it's good that Vim supports it via its remapping capabilities.
But I hear you, sometimes if I have to type the string "jj" I get really confused, but this happens not very often.
> The artificial delay I have to introduce between typing "j" and "k" to actually type "jk" is unacceptable.
I tried the CAPS approach and tried using it via my left pinky, but find it too awkward to use - but this is probably a very individual thing and it's good that Vim supports it via its remapping capabilities.
But I hear you, sometimes if I have to type the string "jj" I get really confused, but this happens not very often.
I go with system wide caps lock as esc also.... it's how I think of "esc" now in any program not just vim
I also bind ALT-J and ALT-K globally to down and up arrows which is super useful when any kind of drop downs turn up and you want to select different options
I also don't use VIM the program that often, more often than not I'm using Vim bindings in other editors. Though they all have their quirks in terms of what they support.
I also bind ALT-J and ALT-K globally to down and up arrows which is super useful when any kind of drop downs turn up and you want to select different options
I also don't use VIM the program that often, more often than not I'm using Vim bindings in other editors. Though they all have their quirks in terms of what they support.
Alternatively, map caps lock to control and use Ctrl-C or Ctrl-[ instead of escape. That way, you can also easily type any other Ctrl+whatever shortcut too, which IMHO is a bigger win than just escape, especially when Ctrl-[ is so super easy to type then.
I use the 'jk' and 'kj' mapping for escape as well, though I've never actually needed to type those characters out myself or at least it's so rare I don't remember. However, everyone is different.
What I'd suggest if you want to give it a try is to also set the `timeoutlen` to a lower value. By default it's usually 1000ms, but that can be dropped quite a bit I believe without much interference.
What I'd suggest if you want to give it a try is to also set the `timeoutlen` to a lower value. By default it's usually 1000ms, but that can be dropped quite a bit I believe without much interference.
autocmd InsertEnter * set timeoutlen=100
autocmd InsertLeave * set timeoutlen=1000This 'jk' and 'kj' mapping works only to get out of the Insert mode. But it does not match the full capability of the original 'Escape'.
- How do you escape from visual mode to normal mode?
- How do you ensure that your abbreviation gets expanded when you escape from insert mode to normal mode?
- How do you escape from operator-pending mode to normal mode? With this mapping, if you press 'd' to delete something and then change your mind and decide to return to normal mode, you are forced to use the original 'Escape' anyway. If you happen to press 'jk' due to habit at this time, it is going to end up deleting lines.
For these reasons, I thought to have a clean mapping of another convenient key (such as Caps Lock) to Escape at an operating system level, rather than trying to make Vim treat some other key as Escape in certain modes.
- How do you escape from visual mode to normal mode?
- How do you ensure that your abbreviation gets expanded when you escape from insert mode to normal mode?
- How do you escape from operator-pending mode to normal mode? With this mapping, if you press 'd' to delete something and then change your mind and decide to return to normal mode, you are forced to use the original 'Escape' anyway. If you happen to press 'jk' due to habit at this time, it is going to end up deleting lines.
For these reasons, I thought to have a clean mapping of another convenient key (such as Caps Lock) to Escape at an operating system level, rather than trying to make Vim treat some other key as Escape in certain modes.
I have had to type jk or kj very rarely that the egronomics of not having to move my pinky to the caps lock key every time that I need to escape is way worth the extremely minor problem of having to wait a second when I need to type jk. Optimize for the common and handle the exeptional.
The inoremap jk <esc>, inoremap kj <esc> configuration gets you back to normal mode only from insert mode. What do you do if you want to return to normal mode from visual mode or command mode?
What if you want to type an abbreviation and expand it when you escape from insert mode to normal mode?
What if you want to type an abbreviation and expand it when you escape from insert mode to normal mode?
> What if you want to type an abbreviation and expand it when you escape from insert mode to normal mode?
I press space or tab or enter or actual escape if I need an abbreviation and it happens to be at the end of what I intended to insert... I pretty much never rely on escape to do the abbreviations though because it's not at the end of what I want to insert anyway.
I also don't use visual mode enough to need to have an escape for it. you can certainly change the timeout on visual mode and add a visual mode mapping for that too if you want to do that. It seems you have a the attitude of this is the only "correct" way to do it. I don't really care if you use it or not... I was merely providing an alternative way to do what you want with the added benefit of it giving you an extra modifier key that you can bind other things to. You can also map it globally or for each of the handful of modes you want to escape from using it.
I press space or tab or enter or actual escape if I need an abbreviation and it happens to be at the end of what I intended to insert... I pretty much never rely on escape to do the abbreviations though because it's not at the end of what I want to insert anyway.
I also don't use visual mode enough to need to have an escape for it. you can certainly change the timeout on visual mode and add a visual mode mapping for that too if you want to do that. It seems you have a the attitude of this is the only "correct" way to do it. I don't really care if you use it or not... I was merely providing an alternative way to do what you want with the added benefit of it giving you an extra modifier key that you can bind other things to. You can also map it globally or for each of the handful of modes you want to escape from using it.
This configuration is commonly known as "lol jk".
I had a really hard time getting into Vim until I found out everyone I knew who was using it had mapped something else to escape. Once I did the same, it was much easier to get started.
For me it was the same. Using ESC is really ergonomically awkward for me. There are also people using Ctrl-C (which works by default) - but I prefer the 'jj' or similar method.
It's also useful to use Bash in vim-mode and also remap the esc-key, e.g.
It's also useful to use Bash in vim-mode and also remap the esc-key, e.g.
set editing-mode vi
set keymap vi
$if mode=vi
set keymap vi-insert
"jj": vi-movement-mode
$endif
You can use Ctrl-C as an ESC shortcut in vim.
That's a highly interactive Vim tutorial. Kudos to the developer
First, learn
Next
Then
Finally
Now you know vim. Don't let people tell you you're using too many keystrokes. Are you still reaching for the mouse? If not, you're using vim just fine.
Most of the good stuff in vim, you'll learn accidentally, because you're in normal mode when you think you're in insert mode, or because you have caps lock on in normal mode and you don't realize it. Pay attention to the bizarre behavior that results and you'll learn useful tricks. Mode confusion is a feature, not a bug.
For the rest, there are certain topics that reward study and are unlikely to present themselves to you accidentally, but there's no hurry unless you're feeling the pain of not knowing them. I recommend:
1. Visual selection mode
2. Prefixing counts to commands
3. Search and replace with regular expressions
4. Advanced cursor movements
Lastly, if you're using gvim, do
at the beginning of every session. Those GUI elements will tempt you to use the mouse, when that's almost never an appropriate thing to do.
Edit: learning to use x and d early on is probably also a good idea, if like me you're the kind of person who makes mistakes.