Not to mention most of the vim keybinding benefits are already there in Sublime.
Most developers I know now know enough vim to use it in a pinch for editing on remote servers. What I'd really like to see to handle even this edge case is a browser implementation of Sublime. Now that would be cool.
No. This simply isn't true, Sublime Text 2 has one of the least complete examples of a "vi-mode" I have used. ViEMU, Emac's EVIL, XVim for Xcode, all seem much better thought out and break less muscle memory than Sublime Text 2's vi-bindings. Sublime Text 2 left out all of Ex... seriously.
The only major upside is that Sublime Text might have a 3rd party step in and fix its broken vi handling (someone started to do this with VintageEx).
Why do we always put Vim bindings on a pedestal? It seldom makes sense - why hjkl and not ijkl? why u to undo but ctrl-Y to redo? -, it doesn't conform to modern conventions, and learning how to use it is a real uphill battle.
One of the more underrated features of Sublime Text is the Command Palette. Just by pressing ctrl+shift+p, you can access almost any command, without having to memorize some arcane shortcut key. It is an incredibly powerful feature - one that I really wished Vim had.
I agree with you. I think he's spot on about how the editor should know more about common languages like HTML and Javascript out of the box. It's frustrating to me that formatting is still bad despite my attempts to make it better.
This is one of many vim plugins for Sublime. I really don't understand posts like this (although it's quite hilarious). Every major IDE and text editor worth consideration has a VIM keys plugin. Other than that, one can find at least two or three IDEs or text editors for any major language that will do what vim does and more. Using the best tools for the jobs is a mantra much repeated but hardly practiced.
Asking a new engineer to work on vim (or emacs or any antiquated editor) would indeed be stupid and I would question any engineer's sanity who would suggest such.
Vim definitely appeals to minimalists and it's non apparent design and GUI makes it sexy. But I totally agree that's it's not worth to learn Vim nowadays and people using Vim in general just want to show that they are some real hackers.
I spend 90% of my time thinking or debugging, not writing/editing, so I feel like it's optimizing the wrong thing. If you're typing with two fingers, don't use any shortcuts and only use your mouse to move around, then by all means try to improve. Personally, I don't feel it's worth it. Sure, you should know your tools, but I feel many programmers take it to the extreme with Vim/Emacs and Dvorak keyboards.
Vim literally saved my career. I have not found a mouse that I can use 8 hours a day (let alone 12+) that doesn't cause me severe hand and wrist pain after a few days. Using Vim, and Vim keyboard shortcuts in every program I can, is the only reason I can use a computer at all. And since I so rarely use a mouse now, I can actually occasionally play PC games again with a good weighted gaming mouse if I don't overdue it. That is a treat.
When I was in my 20's and early 30's I rarely thought about optimizing such things. I thought people who obsessed over Vim/Emacs were a bit odd. Now I'm one of the odd ones. I hope you never have a need to resort to such arcane arts, but if you do, Vim and Emacs will be waiting for you.
Similar story for me, I'm 21 and due to bad computer and mousing habits I have quite nasty RSI/OOS in my wrists.
Switching to an ergonomic mechanical keyboard (kinesis advantage) and a keyboard-heavy workflow (vim) allows me to work as a developer.
I can tell how often I resort to using the mouse each day by the pain when I get home (I have a trackball on my left hand side and a touchpad on my right hand side to try alleviate this), thanks to not using the mouse all day I can often game for a few hours without too much trouble.
This isn't necessary specific to vim, however vim's modality and extremely expressive command language really minimize the amount of movement I need to do for any given action, no more emacs-pinky for me.
My current development machine is running Linux with Xmonad (Vim keybinds). I run console Vim inside Tmux (vim keybinds). I run Vimium in Chrome. I have also remapped the caps lock key to CTRL in every OS I use (all of them) to avoid reaching for the CTRL key. I've also retrained myself to use C^[ for ESC rather than remapping "," or something else. C^[ works in a lot of places too, so that is a nice bonus. I can usually code for hours without using the mouse at all unless I'm using Chrome's dev tools.
Before switching to Vim a few years ago I got a Comfort Keyboard to see if that would help. But after switching to Vim I find that I don't need anything other than a normal keyboard so far. I hope that doesn't change for the foreseeable future.
I hope you continue to find ways to improve your situation. It seems like things just keep getting better for those of us who need to avoid the mouse as much as possible.
Thank you for that insight, glad to hear that you are able to comfortably use a computer :)
As much as I wish you weren't in pain, it is a little comforting to know that there are others in a similar situation.
The main advantage of the kinesis for me is all the buttons around the thumbs and the fact it supports remapping from the device itself, so that whenever I am feeling pain I move keys around to alleviate it (often moving keys away from pinkies and towards the thumbs if I find myself using them often).
I have a windows,alt,ctrl and tab key under each thumb. Shift and backspace under the left, right and space under the right.
On my laptop I have capslock as esc but this doesn't help too much as my pinkies are quite painful to use after a while.
I use dwm, set -o vi for most of my terminals, and pentadactyl in firefox.
Haven't heard of Vimium; I have been looking for a Chrome equivalent as I prefer it as a browser, pentadactyl is nice but it has the issue that it currently doesn't support the use of ctrl-c which drives me insane.
My friends, I had not intended to discuss this controversial subject at this particular time. However, I want you to know that I do not shun controversy. On the contrary, I will take a stand on any issue at any time, regardless of how fraught with controversy it might be. You have asked me how I feel about vim. All right, here is how I feel about vim:
If when you say vim you mean the antiquated relic, the impossibly-steep-learning-curve editor, the maddening modal machine, the most discouraging interface, which infuriates experienced users, confounds new users, and yea, literally takes the mouse from your hands and sets it on fire; if you mean the editor that takes every other editor and stomps them into the floor, shouting all the while, "I am better than you!" as you look on in total despair, then certainly I am against it.
But, if when you say vim you mean the savior of efficiency, the feature-complete friend, the wise teacher, the universal helper, that is there no matter what the task, that asks only for your patience in return for life-long skill, that teaches new lessons right when you think you have mastered it, that frees you from reliance on the IDE and says, "rely only on yourself"; if you mean the tool that becomes a personal, intimate companion to anyone who has the fortitude to let it, then certainly I am for it.
This is my stand. I will not retreat from it. I will not compromise.
I was thrown a bit when he say's "To code in Vim, you have to keep Vim in your head just as much as the code that you’re editing. You have to constantly think about what you’re doing." I have a few coworkers who work completely in vim while the rest of us use Visual Studio. I ask them questions about vim usage and usually they have to think a while about what they actually do because using vim is second nature to them.
I do not have to think about what I'm doing in vim, when it comes to normal text editing.
To be quite honest, getting up to normal-editor level with vim shouldn't take more than a month to become comfortable. Learning to move, yank, paste, and navigate windows is not hard and you really don't have to think about it.
More advanced usage I have to think about, but that's no different than if you had to think about what you were doing in sublime when you clicked search and replace and started typing in a regular expression.
Thanks for this link -- for my coworkers who use Sublime, this seems like it is an improvement over what they do know (create a shared directory on their computer to the VM's files).
In my opinion, relying on keystrokes for doing things is not a problem but a future. If you use Sublime Text very often and try to learn tricks you will find yourself touching mouse less and less.
The problem with Vim is that it is not designed for my shiny MacBook Air keyboard, it can't get benefit from all modifier keys other GUI text editors uses.
I don't know much about computer history, but I believe keyboards that Vim is designed for didn't have any modifier key but Escape. I guess they didn't have Shift too. That's why old programming languages are all uppercase.
If you want ⌘S, ⌘C, ⌘V etc., try Macvim (https://code.google.com/p/macvim/). I use it for longer coding sessions (more colors, faster rendering when in fullscreen with split panes), and terminal vim over ssh when working on a remote server. Also, I map Caps-lock to ESC on my mac, easier to reach (and who uses Caps-lock anyway).
They actually had META, SUPER, and SHIFT (someone please correct me if I'm wrong on which ones. I'm trying to remember which one came from ALT, and which one we now use the 'Windows' key for)
The point is, all modern keyboards basically have what keyboards have always had (unless you're counting those old Lisp machines or a 5250 for an AS/400 or something) 4 modifier keys.
Just use what is most appropos in context. I use vim over ssh connections because vim was designed to be used over slow/high latency connections.
You can't fire up BBEdit or Sublime Rext on the remote end and get reasonable performance locally unless both ends are on a decent high speed network, mostly due to the need for screen sharing.
1. People who want to learn sublime will use sublime.
2. People who want to learn vim will use vim.
I've tried many editors before vim, and now I'm solely using vim, I mean, the whole thing about it. The integration with tmux, ssh, working with all the shortcuts and command magics, its community, everything. I realize this is the editor I wanted to use. I can spend hours doing things in terminal, seamlessly with vim, most of the time I didn't produce either good quality or good amount of code, but I enjoyed every minutes of it.
I'm sure people feel the same way about whatever editor that they use now, if they don't, let them pick whatever new editor they wanted to learn. Why all the hate?.
"The Editor You Need To Read (At Least) Two Books On To Use Well"
Read :help. I haven't read any books on Vim so I'm not sure if there are any good ones, but you most definitely do not "need" to read one.
"The point of a mouse is to make arbitrary on screen jumps efficient, and it’s very good at doing that. Don’t you ever think you can beat a mouse. Only in very few edge cases will it even matter."
That's kind of ridiculous.
When you edit text, your "jumps" are not arbitrary—they have a structure to them, and Vim lets you express your movement within that structure very efficiently in terms of lines, words, sentences, search, etc.
With a mouse or trackpad, you have to move away from the keyboard, make a movement to the general area you are targeting, then fine-tune your target down to a space between two characters to insert the cursor.
"Pathogen, the first widely used, known, and celebrated path manager making plugin management possible, was released in 2008! Before that, you were encouraged to recursively copy the plugin’s directory into your Vim folder."
And before 2008, Sublime Text was nonexistent. What's your point?
I have used a plethora of plugin systems, and Vundle is the pinnacle of all of them. Simple to install, remove, and update.
"700 hand written lines in my .vimrc, and 45 plugins"
I may have found the problem. Learn to use the editor.
As somebody who recently switched from Vim to SublimeText, I agree and disagree with much in the article, but the point about the mouse is interesting.
For years I believed that eschewing the mouse was speeding me up. But I recently had the pleasure of working with a fine gentleman, and a SublimeText user, who is an absolute fiend with the mouse. He has considerably more development experience than I, so it is not an unbiased comparison, but I believe his raw editing speed was a bit faster.
This confirmed my suspicion, originally triggered by reading about the Acme[1][2] editor in Plan9, that such a workflow can be quite efficient.
In my experience (11 years with Emacs, then 8 years with Wily/Acme-SAC/Acme) using the mouse is much more efficient than typing to move the cursor and select text. Acme takes it a step further by binding cut and paste to mouse chords. Guide files are the big win, though, since I edit and reissue commands (highlight and middle-click) instead of retyping them.
I tried Acme, and though it had some good ideas, I found that the execution was sometimes poor. I especially disliked that so much emphasis was put on the mouse with no way to fall back to the keyboard.
Extra ways to do the same thing is the enemy of simplicity and orthogonality. A major reason Plan 9 and Inferno are so small (the plan9port layer is 51.7MB source, the Inferno VM OS is 51.6MB source), and easier to grasp in one person's mind, is that the old Unix guys ruthlessly stripped out extra ways of getting things done, and made sure they ways that were left played well with each other. I keep a much smaller working set of unixy information in my head, while working daily with Acme and Inferno's userland, than I had to using Solaris or Linux and vi or Emacs.
The way I work in Acme, commands (whether built-in or my own) are presented in front of me for execution, so I edit and highlight and execute them. I don't take time out of thinking about code to think about the magical key combinations that do whatever. So it's more muscle memory to commands on the screen and sight recognition than remembering keystrokes. I do recall that many of my Emacs commands were muscle memory, but the more I wanted to use, the harder it was to remember them all. I lost them quickly when I stopped using emacs. Years from now the commands I used to manipulate files in a given directory will still be there in the guide file, waiting for me to run them without error. (I help this along by directory-specific logging of interesting commands.)
I was especially happy to get away from the hundreds of extra options in the GNU tools userland, which made entire other tools obsolete (e.g., sort -u obsoletes uniq, except when you need to uniq -c or uniq -d). All these options are the enemy of clarity in code, so you can more confidently write portable, straightforward scripts, go back to them later and actually read them.
> Extra ways to do the same thing is the enemy of simplicity and orthogonality.
Adding support for moving the cursor with the arrow keys would not involve a very high amount of complexity. I found that Acme required me too much to just let Rob Pike dictate how I should work rather than providing a tool that I can customize to my habits and my needs.
Hey, don't get me wrong, I'm as turned off by Rob Pike's dismissal of everything not in his vision as the next 9fan or gonut. It took me forever to really efficiently use Acme, and no generics means no Go for me, since it's ridiculous to not have map, fold, and filter at your disposal once you've used it in other languages like Haskell, Python, even Perl or the shell. But what's great about his tools is that if you do let them creep into you, your daily practice gets much better because the weight of the environment doesn't slow you down so much.
I believe it depends on the kind of movement you need to do. If you need to go to an arbitrary point in the screen, I agree. However, if you are on a line and want to go to the end of the line, is it not easier to press the `End` key (or C-e for Emacs users, $ for Vim users) than take the mouse and aim it at the end of the current line? Depending on the task at hand, using the keyboard may or may not be faster.
The mouse and scroll wheel work just fine in my VIM in the terminal. I use whichever one is closest at hand (literally).
In any case we should soon have eyeball tracking to move around. and/or leap motion. also when can I simply shout at the screen and get it to do my bidding?
The "problem" with the mouse is Fitt's Law. It is easy to use the mouse to hit large targets but, as the size of the target decreases, the duration and complexity of the task augments.
Since we, as programmers, deal with very small targets, using the mouse is not the most efficient way to go.
Some editors allow us to move very quickly to the next opening bracket on the line (Vim's f{ for example) while most editors can't help beyond a certain point (usually the OS's word-by-word jumps). If the only means you have to reach that opening bracket is a dozen presses on the right arrow or the mouse… well, the mouse may have its chances. When you can do f{ the mouse is simply useless.
Also, the motion of the mouse is non-linear: you have typically a fast startup followed by a progressive slowdown until you reach your target. That slowdown happens because the fast startup was done in the general direction of the target and must be adjusted a few times to hit the target accurately.
Another thing to factor is how often you use the mouse in your workflow.
When I do mouse-y tasks (Photoshop, browsing…), the mouse is my primary way too interact with my programs. My left hand is available for hitting modifiers or changing tools while my right hand is almost always on the mouse. In that context, I never loose the pointer and the mouse. Changing from task A to task B with the mouse is easy and costless.
When I do keyboard-y tasks, the keyboard is my primary means of interaction. I can spend a lot of time typing stuff, moving around… without touching the mouse. When I want to use the mouse I usually don't really know exactly where it is — that's a first problem — then, when I grab it, I don't know where the cursor is — second problem — which makes the initial targeting slow and error prone. Once the first steps are dealt with, the limitations in Fitt's law apply.
That's why the mouse is frowned upon among people who use primarily the keyboard.
I do always set up my mouse to have no acceleration. You are right about it.
However, how many people who frowns mouse use knows that you can select a word by double clicking on it, or that you can extend a selection using shift+click, or that nothing scrolls a document as fast as the scrollbar or minimap?
Those are part of the first things you learn in your first hour in front of a computer.
I think that my comment is clear on my position on that "mouse debate": the mouse is an effective interaction device in more than many contexts but there's at least one context where using the mouse is not the most effective thing to do.
Again, the problem is not the mouse itself but the cost of constently switching between it and the keyboard.
Even if the mouse were quicker on average for long jumps, the moving of the hand from mouse to keyboard feels like more of a combo breaker, more distracting. Speed is very important, but equally important is for the editing experience to have a low attention footprint to leave more space for the train of thought behind the changes being made.
As someone who uses a keyboard 98% of the time, but who uses a GUI editor and the mouse when it makes sense, I'd say the mouse is useful for several things, and what it IS useful for WILL be faster than what someone can do with a keyboard.
The clear win is using a powerful GUI-based editor that has tons of keyboard commands. Bonus points for being on Windows or Linux (i.e., not Mac OS) so you can navigate/BROWSE the menus from the keyboard.
I don't know Sublime myself; I'll have to check it out. For some reason I thought it was Mac-only, but I see that it's cross-platform. My editor-of-choice for years has been Visual Slickedit, but I'm not married to it. I just haven't found anything half as good in years of searching. And I keep trying other editors, too, since there are things I find imperfect about it (the scripting language is usable, for instance, but has it's own syntax and quirks).
Tried Zeus probably 4 years ago. I really have tried a lot of options, but I haven't been back to Zeus after the first try. I can't remember any specifics of what turned me away from it, though the thing that SlickEdit does better than almost everyone else is tagging. I use boost::shared_ptr (and now the C++11 version) a LOT, and so completion is useless in anything that doesn't know how to complete a template class. ctags and its ilk, last time I checked, were worthless in this regard, and I have a vague sense that Zeus relied on those for tagging? Yes, looking at the web site, you're using ctags. Will "shared_ptr<Foo> foo; foo->" autocomplete for members of Foo?
SlickEdit also Just Works with tagging. You put the files into a project, and everything is instantly cross-referenced. "Where is Foo::init() used? No, I don't want Blah::init(), just Foo::init()." SlickEdit, at least SOME of the time, can get that right, and with no configuration of external tools.
Aside from that, I think one of the greatest drawbacks of Slickedit is that it isn't open source, so when things go wrong I can't just fix it. Slickedit IS cross-platform, at least, with native Linux and Mac OS versions, and that ALSO is important to me.
Lua is the Right Answer for scripting, IMO. The rest of the options are actually a liability for me, since it means that if I'm editing someone else's script, I might have to deal with Python, TCL, or JavaScript.
I'm rambling now. I feel like I have an "Editor Manifesto" in my head that wants to get out, but I don't have time right now to do it justice. I'll take another look at Zeus when I get a chance, just as I'll take another look at Sublime and the rest. It's been years since I've looked, so I'll take another glance at it.
I'll have to give that a try. I've had countless people tell me it COULD be done, but when I drilled down what they were really telling me was that there were keyboard shortcuts.
If you're telling me I can hit Ctrl-F2, then that's at least a step in the right direction. Thing is, it's several steps behind where I would be on Windows (or most Linux desktops), because I can just hit Alt-F and it opens the file menu, or Alt-T for the tools menu, or what-have-you.
I don't use the menu much so I tend to use the trackpad for that. You could also try KeyCue [http://www.ergonis.com/products/keycue/ ]. You press the Command key for a while and all the options are shown in a popup.
Nice! I'll check that out the next time I'm forced to work on a Mac (it happens when I do any iOS development...oh how I hate Apple...). KeyCue is a step in the right direction, UI-wise, regardless.
His point about touchpads is spot on though. I often find myself jumping around by clicking when I code with my laptop and no peripherals (there's no "combo breaker" since my hands are sitter so close to the trackpad anyway), but when I get home and plug in my mouse and external keyboard, it becomes much more of a hassle to click and I switch to a more keyboard-centric workflow.
In fact, it's the opposite. Using keyboard commands for movement is more distracting (and measurably slower) than using the mouse. It is precisely that the mouse is less distracting that tricks the mind into thinking the keyboard is faster. See AskTog:
[If you think this is incorrect, providing links to scientific evidence is more productive than downvoting or stating that your own subjective experience is different.]
It's not an appeal to authority: that would be if I were appealing to the authority for the authority's sake; but I am appealing to scientific research presented by the authority. I'm fairly certain you'd agree that appealing to scientific evidence is valid, as you've tried to present it to me as part of your argument. I think the downvotes are because you running some kind of "experiment" on your own is different from a human interface researcher's actual research.
Fair point, however the choice of editor/editing mode is a personal one. Are my personal results of my personal experiment not the only ones that matter to my personal choice?
You're not reading some of the most cogent arguments here: most vim/Emacs/etc power users couldn't even tell you what keyboard command to use precisely because they don't think about it. It's reflex, muscle memory, completely out of mind so that it doesn't get in the way of getting code from your mind to the machine. Maybe it's that way for some mousers as well, but given that code is text, it's kind of doubtful. There's also the fact that if you have to break your concentration to context switch to the mouse, you will lose your flow.
Try coding in an editor, any editor, for 8, 9, 12 hours a day and see if you don't start forgetting the keyboard shortcuts because they become reflexive. Vi and Emacs are just hyperdesigned to enhance this effect.
EDIT: And I don't care that you link to Bruce Tognazzini, a GUI designer, when millennia of musicians have known that they don't think about what combinations of fingers they press to get an F#, they just play a glissando with an F# in the middle.
The thinking is subconscious: you don't know you're doing it and you "forget" how long it takes, which is why you perceive the keyboard as faster. If you bother to read the research I've linked to, it covers all of your objections. I know it's difficult to let go of subjective impressions, but the stopwatch is always right compared to our own internal sense of time.
I tend to memorize the spatial location of keys (end, home, parenthesis, cursor keys) and of course, can touch type. Going back from using the mouse to touch typing is so immediate than I basically never notice it.
I think your last sentence supports Sublime Text even more than it supports Vi(m).
You don't even need to read :help right away. All you need to do is:
1. Start the graphical version, i.e. gvim, MacVim, or any version with drop-down menus.
2. Press 'i' to enter "Insert mode". Now just use it like any other text editor.
3. Use the menus. Note the equivalent commands (which are listed in the menus). When you want to use those commands, press ESC to switch to command mode, then enter the commands, then press 'i' again to go back to insert mode.
That's it. Modern vim has one of the smoothest learning curves of all software.
I'm guessing this means you use :Ex instead of nerdtree? I guess you use vimgrep instead of ack.vim or others? I'm guessing you browse your undo tree manually with :undolist ? Can you please write a blog post explaining how to use all of these efficiently? Can you also document how you see inline git changes to the file you're working on? While you're there can you also explain which part of vanilla vim lets you do fuzzy file finding?
Learn to use the editor? Are you just editing your visual basic files or what?
Edit: if you could also point out which of my vimrc lines are fighting against the vim way and demonstrate that I don't know how to use my editor, that would be super cool.
Vim is one of those things you have to suck it up and learn it but after you did, it's so much more productive than most other editors. Editors like subl may seem friendly to beginners but your productivity never grows the more you use it. I use vim exclusively and I have co-workers who only use subl, and I can confidently say I can edit code at near the speed of thinking, which is not something I can say for subl users after pair-programming with them.
You just have to learn it, period. It seems daunting but it's not as hard as some people make you believe it is. I admit vim's plugin system is bad and vim doesn't have a nice API subl has for extensions, but there are experts who write great vim plugins so you don't have to and worse comes to worse, you don't have to load up your vim with plugins to be productive. I have another co-worker who uses vim and is very productive and does not use any plugin at all.
Finally, if you're a new developer, don't listen to the op. Spend a few weeks to learn vim, or emacs for that matter, and you'll be so much better off in the long run.
I learned emacs first and became reasonably proficient in it. Some years ago, I joined a company where most people used vi. I saw it as an opportunity to use vi (also vim) and I already knew a bit of vi from editing unix config files.
I spent almost 3 years working exclusively in vi. I got used to it enough to handcraft my own .vimrc file, use multiple buffers, integrate with ctags, etc etc. I think I was reasonably proficient in vim at that time.
At around that time, I did a coding project with a friend who was an emacs user and when I say him code I thought to myself "Wow, he flies!". That day I dumped vi and went back to emacs. I've never looked back.
Emacs' macros, different modes, integration, shells, etc, etc, let you deal with all sorts of systems in a pleasant way. Learning emacs is a much better investment than vim.
... you should read up on the new hotness in emacs, finally making people really proficient editors -- it is called "EVIL" mode, it is taking the emacs community by storm.
I hear you. My point is either vim or emacs is a much better choice than those "beginner-friendly" editors that the op would recommend to new devs. Simple: no pain, no gain. Both vim and emacs are painful enough for most people to learn, but the reward is substantial and long-lasting.
Side note: I think I'd love emacs if I hadn't learned vim first. Having a real programming language (elisp) for configuration and extension is nice.
Sure, but for the record, Sublime isn't exactly a "beginner-friendly" editor in the "click and drool sense". It offers menus for common operations, but I think of it more as Emacs But With Python than something I'd hand to a new user.
I think the OP has never seen a very efficient VIM user crack some code. There are some valid points but they are surrounded by unnecessary ranting and lack of knowledge.
>> Don’t you ever think you can beat a mouse. Only in very few edge cases will it even matter.
Already saw someone clicking the "Search" button on a google page instead of pressing Enter? This is the same sensation I get when I see someone editing code with the mouse. These same people also scroll a document instead of jumping to the definition or using incremental search.
Btw, not that I have something against programmers who use the mouse in their editor. Just don't say it's as fast because it's not.
Many of the most productive programmers (in terms of text editing ability) I know are heavy mouse users. Watching them work really opened my eyes and taught me a few good habits. One of the skills that you have to develop is the ability to hit very precise targets with the mouse very quickly. I think that a lot of people are simply inexpert with the mouse and misclick a lot, and that adds to the perceived cost of the mouse in their head. But I assure you that if you can reliably hit targets with your mouse it will unlock productivity doors for you.
Want to rename an identifier? Double click it with the right hand, Ctrl-<replace> with the left, tab with left to proper position in dialog while right hand is returning to home, type replacement, hit enter a few times.
Adding a prefix to a bunch of strings? Click-drag to select the prefix while hitting Ctrl-C (stretching the pinky to reach the Ctrl takes about as much time as the entire click-drag), click click click on all the places you need it to go, timing the clicks with Ctrl-V on the left hand, scrolling with the wheel as needed. Very, very fast.
I suppose that describing it doesn't do it justice; I certainly wouldn't believe it if I hadn't seen it with my own eyes repeatedly.
Yeah, he had some odd examples. If you can't type "/word<cr>" faster than someone can move their hand to the mouse, target the word, and click it, then you can't touchtype. That was a strange example of his.
But nevertheless, I would happily take up his challenge: let's find a word that is in the document, but not currently on-screen - hardly an 'edge case', more like 'routine task'. Good luck at winning that one, mouseketeer!
Another great one that sees regular use at my fingers is ci' or ci" - again, hardly an edge case, and blazingly faster than selecting the characters just right with the mouse.
I have no problem with using the mouse for certain things, but blanket statements like the quoted one are rarely anything but wrong.
If I am looking for a particular word, then I will use a search. Even notepad and nano has a short-cut key for a simple search for a particular word.
Where I find a mouse useful is when I want "that loop which I suspect is misbehaving. That one which adds a new member to all arrays". There a quick flick of the mouse-wheel, and then fine positioning of the mouse cursor I find gets me to my location faster.
Even when the loop is on the screen, maybe 35 lines up, I have to either do a binary-search style jump with the keyboard, or with the mouse just click on it.
Also, looking for a particular word is easy when there is only one occurrence of it, or you want the next occurrence. A mouse might still be useful when there are many occurrences of a variable and you want (for example) one somewhere near the end.
Perhaps vimmers tend to keep better track of where everything is to make it easier to "hard jump" to, while mousers tend to keep a more ad-hoc overall view, so they know approximately where to scroll to?
My .vimrc is the following:
<quote>set number</quote>
Which shows the line number no matter what in a vi editor.
Jumping to a loop on the screen is as easy as viewing the line the loop is on, then hitting colon+line number (e.g. ":68"). This might be what you're referring to with a "hard jump".
I also use the "number+command" shortcuts quite a bit. If you want to jump up/down 20 lines (or 2000), then "2000k" or "2000j" will move the cursor up 2000 lines or down 2000 lines. Also a hard jump.
But to find an occurrence of a word at the end of the file, the typical search sequence is the following:
1) :$ - this jumps to the end of the file ($ is a common regex meaning 'end of', the same way that '^' means beginning of)
2) ?word - this does a backwards search for the word. this is at the bottom of the file, searching upwards
3) n - this jumps to the next occurrence of the word
So thats like 5 keystrokes not including typing in the word. Jumping around and viewing files really is neat with vi/vim.
See, I have tried so many times to use and love VIM, but I can't. I feel its a monstrosity. I find "nano" 1000000x better for quick editing on a server. Most servers I have worked with, have it. I only use vi/vim if i REALLY REALLY have to.
Hell, I even did VIM Adventures. I like a lot of the hotkeys and shortcuts for stuff, but its weird.
I am much happier and productive in IntelliJ and Sublime. and if I do something in command-line. Its Nano that I use.
I think its mostly the hotkeys and the lame "insert" and "command" mode seperation. I want to be in both modes. Hence I like the hotkeys on most IDEs.
You are never in both modes. In another editor, as soon as you press Ctrl, you have flipped the mode. 'command' mode is a bit like having a 'ctrl-lock' key.
a) Never thought vim was that hard to learn (and I first learned it when I was a teenager and nobody helped me. I switched when someone on a MUD made fun of me for using pico.)
and
b) Thinks vanilla vim works just fine. Seriously my vimrc is like 10 lines long and I don't even have it on every server I work on. I don't bother with any plugins. I don't need vim integrated with git, I don't need it to do anything except let me edit text efficiently.
I dunno maybe I'm crazy.
EDIT:
I also often feel like I'm alone in not treating what tools (including text editor) I use like it's a religion. I don't care if anybody else uses vim or not. People should use what they wanna use, what do I care?
These kinds of rants make me wonder what kind of medication the OP stopped taking. If he hates vim so much stop using it. It's clearly causing him a lot of misery.
There is nothing wrong with using them, except that (as the article points out) they don't work terribly well, take a lot of effort to get right, and aren't the focus of the editor.
Sublime and Emacs are joys to extend versus Vim, that doesn't mean it can't be done, just that it is tough.
Yea, I use vim for editing files quickly in a terminal, 90% of the time im working in a windowed environment and use sublime, but when im putty'd into a server and need to quickly modify my nginx.conf. vim\r\njji
I switched from nano to vim a few hours ago. When I first installed Arch Linux all those months ago I was intimidated when I was presented with the choice between nano, the default, and vim, "for experts only." When I used vim for the first time today I expected it to be a lot more "difficult" based on everything I had read/heard prior, but after reaching the Arch Wiki entry I was able to hop right in with no difficulties at all. Honestly, the biggest "challenge" I'm facing so far is just getting used to typing "vim" when my brain is used to typing "nano." I'm not denying that vim is complex, and it will probably take me months to "master" it and use it to its full potential, but it isn't hard to just jump into and use, and like you mentioned vanilla vim works perfectly fine.
Just out of curiosity, what made you decide to change? I've never felt a strong motivation to not just keep using pico/nano, actually putting effort into learning a text editor strikes me as the weirdest hobby ever.
I used to use nano, and for me it was the fact that every one else seemed to love vim, so I felt like I should at least try it out. Honestly, it takes about 20 minutes, max, to get to the level of being able to do what nano can do in vim. And if you want something more, it's not very hard to learn after you get the vim basics. I'm not going to say it's for everyone (especially if you're already used to a full IDE) but I would encourage anyone who's at least a little interested in trying it out for a day.
One time I started editing an nginx.conf file in nano while setting up a remote server on Linode. I forgot to sudo when I opened the file and couldn't save my changes. I might be an idiot here but (could I have resolved this in nano?)... but I'm fairly certain this would have been a non-issue in Vim.
One simple solution that people often forget - at least I know I did in this situation is to save the file in home directory and then move it using su(do).
It just happened to be a good time to switch, to be honest. I've migrated from Openbox to Awesome WM in the past few days, and I needed a good editor with features like syntax highlighting, line numbers and great community themes as I learned my way around rc.lua. Also, as mentioned previously, Vim has a "reputation" for being difficult to master. It interested me, and all of the Linux gurus I know seem to use it, so I figured I would give it a shot.
Once you learn to jump quickly between words, lines, etc. and change whole blocks of text with a few strokes you discover another dimension of vim that's very hard to replace with other tools.
C-a and C-e and a dozen of others are there, yes, but good luck if you think you can use M-%, M-h or whatever is the Emacs equivalent of Vim's text-objects and motions (which is what the parent was thinking about).
I actually think people who use esoteric tools are more interesting than people who think that one tool is the best. And I've been working professionally for well over a decade now.
>Never thought vim was that hard to learn (and I first learned it when I was a teenager and nobody helped me. I switched when someone on a MUD made fun of me for using pico.)
I'm pretty sure as a teenager is the best time to learn such tools. :P
Yeah, I learned Vim before I was a professional programmer, too. I think that practicing programmers get more frustrated, because the learning curve is really disrupting their productivity.
I started with gvim, then eventually got comfortable. I never felt like I had to cram down vim facts. I just took them as they came.
Don't know about a) - can't remember. I'm just happy with my vim skills as they are now. Sometimes I come across a tip showing a trick or two that I didn't know.
Totally agree regarding b). I like to be able to jump on a random machine and NOT miss overcomplicated .*rc configuration. My .vimrc is 11 lines long, including 3 comment lines and to blank lines....
Vanilla Vim is pretty sub-optimal for writing prose.
Vim is my text-editor of choice, but it took me a lot of time and effort to customise it to make it more suitable for writing prose.
E.g. the fact that it scrolls by logical lines rather than screen lines (note I that I said scrolls. I'm aware that you can navigate by screen lines by using gj and gk). The way this makes the text scroll by unpredictable amounts when you have paragraphs of text is pretty jarring. You can hack around that by getting the text to auto-format and break lines up into screen lines, but there's all sorts of niggles with that (and FWIW, it causes some of its own problems, such as making it harder to search for phrases, because words may no longer be separated by just spaces but also possibly linebreaks).
My own vim-seek was created for navigating long sentences easily; criticmarkup is a superset of markdown for cuts and other edits, which I ported to vim. And vimroom offers a IA Writer-inspired experience. For what Scrivener and outliners offer I'm working on something to scratch my own itch.
What else would you find missing for a writing workflow?
autocmd FileType text set textwidth=75
autocmd FileType text set formatoptions+=a
autocmd FileType text set formatoptions+=w
explanation:
- formatoptions+=a: auto-format as you insert text, which means it will (basically) automatically insert a newline once you've typed 'textwidth' number of characters on your line. it will insert a newline while you are typing.
- formatoptions+=w: this isn't necessary, but it has an effect on the way the auto-formatting is done. i find the 'w' options more convenient. With 'w', a linebreak means a new paragraph, unless trailing whitespace at end of line. It means that the 'a' option doesn't auto join lines separated by a linebreak.
- if you're not familiar with Vim's autocmds, what they're doing in the above definitions is setting those options for any text files that are opened (and only text files).
I'm the same really. I had to learn vim when I started at a games company that had a Linux build chain. I printed out the keyboard quick reference and was reasonably productive after a few weeks. The only plugin we used was ctags, to be able to find shit in our massive C/C++ codebase, but that worked ok (despite having to manually rebuild tags yourself).
I agree with the author - I'd also recommend Sublime Text 2 - but vim fills a great niche - when you only have a telnet terminal, so it's always good to know the basics.
Dear God, we're talking about what programmers spend the majority of their working hours using, for the foreseeable future. I suppose you never learn new programming languages, because god forbid, you're gonna be crippled for some time getting around new frameworks there and who really wants to make investments?
In all fairness, the argument being made is that learning vim is a waste of time for programmers on a deadline who don't already know it, or they wouldn't benefit from it. I have made the same argument about learning PHP, MATLAB and C# (while at the same time being eager to learn about just about any language new to me, eg, Go, Scala, Clojure, Haskell, etc).
The OP has a really "sane" take on things imho (yes, it's incredibly opinionated, but it's blog post featured on HN, not a SO question someone like you can close in minute :) - and I'm glad he bothered to write it, as I'd probably just send the link to it to any newbies asking me about "the magical vim" instead of bothering to tell them what I think) and he's right on one thing: vim will not increase the productivity of a new user. The actual productivity increase will only happen months later (basically too late to worth it), and it will not matter that much because 90% of the time spent coding is actually spent either:
(1) plainly writing code (no advanced editor functionality helps here, Notepad++ is basically good enough!),
(2) making simple edits to code (again, more editor functionality doesn't really help because 90% of the time spend editing code it actually spent thinking about what to edit, not actually pressing the keys)
(3) reading code,
(4) exploring codebases (the only thing helpful at this is a full featured IDE - it just takes too much work to turn vim in to something like this, and you'll just end up with something mostly matching Netbeans feature-wise, so you could just as well install Netbeans or something else better for your language/framework in 5min and spend 1h to really learn how to use it),
(5) debugging (again, the only thing that could, for some, including me, increase productivity, is a full-fledged graphical debugger).
...and if you need to improve that last 10%, then you are far from a beginner at anything, eg. you are not the person that vim tends to be recommended to nowadays.
And the OP also expressed why I like ST so much: "To code in Vim, you have to keep Vim in your head just as much as the code that you’re editing. You have to constantly think about what you’re doing." - at most (not all) things ST beautifully follows the "don't make me think" principle: eg. arbitrary multiple cursors (no other IDE or editor besides Notedpad++ has them yet, no matter how many users requested this for JetBrain IDEs for example), that just let you "edit without thinking", keeping the code in your working memory instead of the sequence of search and replace commands.
But all that said, I absolutely love vim's keybindings and modal editing concept, so I tend to enable vim keybindings or install a vim-emulator plugin on most IDEs and editors I end up using because it also spares you of having to commit the different shortcuts that every other IDE and editor uses to "muscle memory". I see vim like more like an uptional UI/X layer that should be addable to any decent editor or IDE to enable experts to improve their 10%. Fortunately Sublime text has such a "layer" so OP's post is kind of valid.
can it select, copy, paste and do zen-coding like expansions in multi-mode? if it can't do all of them or I can only use it to insert multiple cursors at search points (like the emacs multiple cursors plugin, sigh) I'll consider it useless for my workflow.
They're GREAT for refactoring. Select something. CTRL-D a few times to keep selecting other instances of the same thing. It's not global find and replace.
Or, when you have a nice set of lined up/indented declarations, it's trivial to just right-click+SHIFT and drag a cursor before every line and start typing.
I said "arbitrary" exactly to differentiate from the emacs multiple cursors: I need to either add a cursor to each line of a selected region or add them based on search keywords, I can't just mindlessly ctr+click in 3 completely different non-adiacent places and have it work (or can I?).
It is absolutely incorrect that you have to 'keep Vim in your head just as much as the code that you're editing' unless you have not learned Vim at all. The reason you don't (constantly) have to think in ST or notepad++ is because you have already learned that editing paradigm. Although, that editing paradigm IS more obtrusive than vim's. It's abundantly clear that you do NOT understand vim's keybindings and modal editing concept, if you constantly think about vim.
vim has code exploration tools integrated: they just have funny names like ctags, grep, cscope. If you want them. You can also just use separate tools for browsing vs. editing, with no obvious productivity loss.
The productivity impact of having the debugger in your editor process cannot be a big deal, and it's pretty weird to hear that this is essential right after you stress that notepad++ is good enough. Which one is it?
If the point is that you spend most of your time writing, editing and reading code and otherwise the only advantages are in heavy-duty tools not present in ST, then the implication isn't that it's "sane" to reject vim, the implication is that it doesn't make any difference what you use.
notepad++ is good enough for editing, not debugging, I didn't say that. I reject vim as a "general purpose programmer's text editor" and I reject recommending it to someone as such, but it's probably great for someone neck deep in nix sysadmining - actually that's what I use it for, on the server to quickly edit some configs, but on my laptop or desktop I just never touch it... and I also reject the vim way from a more "philosophical" pov: as an UI designer, I hate modal interfaces - if you have to think of or remember where you are, in order to know what you can do, or where to go in order do do some thing, then that UI needs a manual/guide, therefore it's broken by design (no, I never rtfm :) ).
I am not a UI designer, but I don't buy into the idea that this blanket notion of "modal interface bad" and "oh, it's got a manual? it's broken" applies universally across all interfaces for every use case. Or are you being facetious?
When we're talking about a text editor for programmers, I don't need it to be usable by somebody who doesn't grasp the domain to begin with. I'll gladly give up some UI sugar because in this context a modal interface is exactly what makes me so productive with it and partitions the complexity into composable chunks that are easily reasoned about.
Well, I do use vim, so I can't really hate it, can I? :) ...it's just the thing that some things should just be plain and simple imho, code editing should not be a "domain" in itself and one should rather learn unrelated new things than bother tweaking that last 10% ...it's just a matter of preference and take on life, some strive for "mastery" at something and work on that last 10% to get an edge, others don't bother to achieve "mastery" at one thing but prefer to explore more things and get that edge by "perspective shifting" or "thinking more outside the box". I bothered to learn vim out of "exploratory curiosity", because I found the concept of such an interface interesting. But though interesting, I don't consider it a good idea anymore - if you give people a tool to manage complexity, they will take advantage and add more of it, for very little benefit.
I guess I look at vim as less an interface that a user needs to become familiar with and more of a language that one learns to manipulate text. For example, I don't think the same design principles that go into maximizing conversions on a website necessarily apply to learning Russian. The tradeoffs are different, as is the payoff.
"at most (not all) things ST beautifully follows the "don't make me think" principle: eg. arbitrary multiple cursors (no other IDE or editor besides Notedpad++ has them yet, no matter how many users requested this for JetBrain IDEs for example"
What do you mean by "arbitrary multiple cursors"? Do you mean the thing that all Scintilla-using applications (which Notepad++ happen to be one of) have?
I said "arbitrary" because a number of editors like emacs or jetbrains IDEs have some sort of multiple cursors or square selection, but they just don work in simple way like ctrl+click to put them anywhere or allow breaking up the selection into lines ..."arbitrary" is not the right word, I know, I mean more like "multiple cursors done right" :)
Honestly, I can't remember finding a recent text editor that couldn't do it, TextAdept being the latest one. Sublime Text definitely has major selling points (in the sense of having advantages compared to other editors) but this is hardly one of them.
Can you tell of any IDE editor that has this? (Eclipse: nope, Netbeans: nope, all the Jetbrains IDEs family: nope, Visual studio: nope / actually there's one handicaped plugin to sort of do it in VS)
eg. arbitrary multiple cursors (no other IDE or editor besides Notedpad++ has them yet, no matter how many users requested this for JetBrain IDEs for example)
I have the same setup as you - vanilla vim, barely customized and the development pace is hardly any slower than when I use Visual Studio with all its auto-completion, deep syntax parsing, etc. I saw Jonathan Blow (of Braid) saying that auto-completion and better debugging support is a deal-breaks for him, but everyone`s work pattern is different and I`ve seen plenty of cases where people using vim accomplished far more and faster than those with fancy editors. Tools are important, but they are secondary.
I use plain vi[m] for several reasons but mainly because I used to visit customer sites all the time and have to use their environments. If I need to edit a whole bunch of files I needed to do it with what the customer has installed, and the bare minimum to rely on is plain old vi.
My .vimrc (if it even exists) contains:-
set background=dark
That's it, and I generate that by hand whenever the syntax highlighting begins to annoy me if it isn't set. I've never used or even looked at a vim plugin.
Of course plain old vi has its limitations but I know what they are and have pretty good ways of doing anything else I need to do.
Same here. Never remapped the leader key, tried and ditched pathogen, never used gvim, never used hill, but I have checked 2G in vim, and I know how to do some advanced search and replace, I have python errors in red as I type and I got once in the highlight engine to fix an annoying color.
You're not crazy, you're spot on. As long as a new user understand vim insert and command mode (and how to :w) then they should be as productive as if they were using any other editor.
When I started learning vim all I knew were the command modes and how to move around using hjkl. Slowly over time I added more commands.
I have started using vim just a couple of years ago, much later than I've started coding and got introduced to vim. Initially I thought that vim is for hipster nerds who would rather use something awkward and completely ignore some useful mainstream stuff like arrow keys and a mouse.
Later I've developed a wrist pain and got interested in ergonomics. One thing I've noticed was how badly the arrow keys are positioned and how "unhealthy" it is to use a mouse with a right hand (numpad shifts the position of a mouse too far right). And then I started thinking about minimising use of a mouse and arrow keys. This led to the rediscovering of vim.
It was surprisingly easy to learn and later surprisingly hard to use other editors.
a) Never thought vim was that hard to learn (and I first learned it when I was a teenager and nobody helped me. I switched when someone on a MUD made fun of me for using pico.)
Yeah, I was rocking vi in high school, and I'm no genius, I had an ULTRIX vi reference card. The article's assertion that you have to read any books to use vim effectively is bullshit. As for the religion part, that usually comes in when someone tries to dictate what editor other people will use. I don't give a shit if someone on my project uses Eclipse or MSVS, just don't take my Emacs away.
Since he mentioned indenting, let me ask: how do you properly indent JSON or XML in Sublime Text 2 out of the box?
I've tried setting the appropriate syntax, selecting all text, then doing Edit->Line->Reindent but it gives half-broken results. Is that intentional, or am I doing something wrong?
Also, is there a way to quickly select all instances of currently selected identifier within the local scope? Selecting one _highlights_ all other local scope instances, but how do I make it select them all with one action?
Thanks, this is the best I've found. But it doesn't select all the instances within local scope (which happen to be highlighted, so it's not stretch to imagine being able to select them all), you end up having to do it manually by starting with the first entry and then carefully select all others that still fall within the local scope.
Isn't it a pretty common thing to rename local variables? I'm not sure why it's not a readily available feature.
I'm probably forgetting something but it should just be setting the terminal window to 10000 characters. So basically for the entire document word wrap won't happen automatically until a line reaches 10000 characters long.
I think he has a typo at the end which should be gggqG where gg means motion to top of file, gq means reformat over a motion and G means motion to end of file.
Hooray, another tools discussion where nothing gets resolved.
Tools are a highly personal topic, what works for one person doesn't necessarily work for another.
My advice is to try using one and only one new tool a week. By the end of a month you'll have a good idea of what your own preferences are and the relative strengths/weaknesses of others.
With editors, that'd probably be a gamut of vim, emacs, Sublime, Eclipse, and Visual Studio Express. If you're a Java developer, IntelliJ is worth looking at.
> [...] I’m going to go search for how to do it. I’m probably going to learn something in the process. At year 4 of Vimming.
I don't get why this is a bad thing. I've been programming for decades and still learn new stuff every week.
It should be noted that vim and emacs definitely appeals more to the maximizer over satisficer personality:
1. I like learning new tools and I got pretty good at vim's 10-15 fundamental commands in probably a couple of weeks. I was certainly OK, albeit a bit slow, by day 2 or so.
2. By the end of month 1-2, vim had become completely second nature. I did stuff without thinking. Actually, thinking about what I was doing started to confuse me.
3. Sure we all spend lots of time thinking, but I also often find myself cranking out code and vim is quite amazing for that.
4. I ended up switching to emacs because a) I like learning about tools (see #1) b) emacs gives you a more IDE-like experience c) while retaining 90% of vim's editing power d) and in general has the similar "become an editor expert" philosophy to optimizing editing workflow
I haven't used sublime, but I'm quite fond of editors that are keyboard-only (especially for jumping around, etc.), cross-platform, have stood the test of time and have endless extensibility.
edit: I have customized both vim and emacs to crazy depths. There was a time when just as I started to code, I'd say "why can't I do this [blah] drudgery automatically?" and end up writing an emacs function to do it :-)
I rock back and forth, depending on the languages I'm using. Emacs does more, but is in my experience more kludgy, even after having in aggregate spent many days customizing it (maybe it would rub better if I wasn't hardwired to the vi/vim modal editing/motions method). Vim feels cleaner and less annoying, but sometimes the easy integration with external tools tips the balance in emacs' favor. E.g. I use vim for Rails apps (where I didn't really feel enough difference from vim + terminal), but if I were writing Clojure, stuff like the repl integration would probably mean emacs.
Sublime is really pretty, and has great functionality out of the box.
Ultimately, vi/vim's contribution is the modal editing method (and derived things like motions), which can be transplanted to any other IDE or editor that cares to support it. But for the fundamendals - editing and switching between files - I've so far found vim to be the cleanest, most natural vim.
Emacs can be pretty pretty--perhaps not actively pretty, but very elegant in a minimalist sort of way. I'm pretty happy with how mine looks[1], for example.
Indeed! I disagree with people who think vim and emacs are ugly: they have their own nice 8bit-esque aesthetic which I'd expect hackers to like, given that they've chosen to stare at terminals all day (I've rolled my own colorscheme for both vim and emacs). And they make good use of screen real-estate, very important when coding on a laptop.
I haven't tried Evil, in my last emacs phase it wasn't mature yet IIRC - maybe I should give that a go and see if it tips the balance yet again.
> Emacs can be pretty pretty--perhaps not actively pretty, but very elegant in a minimalist sort of way. I'm pretty happy with how mine looks[1], for example.
Obligatory vim can be pretty too, and I am happy with how mine looks.
> What's your theme, BTW? I also like your custom status bar shape.
My screenshot doesn't have custom status bar shapes. GP does. Anyway, for that, you need powerline(available for both vim and emacs).
My color theme is ir_black https://github.com/wgibbs/vim-irblack If you are using it in terminal, you also need to set up ir_black theme for the terminal.
Yep, after bouncing between vim w/plugins and Sublime Text for the past year or so, I spent a day messing with emacs and have somehow found a sweet spot for my workflow. (haskell-mode/ghc-mod and AuCTeX - schoolwork) I've tinkered with emacs on and off over the last decade but somehow for what I'm doing now it just feels better than my vim setup.
Agree; customization and extenisibility of emacs is something unmatched (not a vim user, can't comment on that), I have been using emacs for just an year now; and still I feel I am more productive in emacs than anywhere else, keyboard macros and elisp extensibility can almost bring any feature customized to your fingers.
I have to agree with TFA here... I just don't see the point, and never have. When I'm in an editor, I mainly want to type, and have what I type go in where I type it... I like pico/nano over vi/vim/emacs. I like sublime, but a lot of functionality is only keyboard accessible, and I haven't take n the time to learn hot keys... why I would really love is having my editor, and a couple command/console prompts in the same UI. I find that I tend to reach for sublime, as my former fav (Crimson Editor) was windows only, though I could get it working in WINE, wasn't as friendly, and doesn't work with the windows security model since Vista (I use Win7 at work).
I also appreciate what an actual IDE offers in those environments. I use VS (C#) and WebStorm (NodeJS) more than anything lately.. and wouldn't give them up. I'm impressed when I see people get work done in VIM... I just don't think that way, and don't manage to memorize a bunch of hotkeys I don't use at least 10 times a day. Hard enough keeping the step keys for debugging in different IDEs straight, let alone, more esoteric things.
I don't mean to disregard what you said or insult your approach just because it is different than mine, but I can't tell you how much vim/emacs have boosted my productivity. Not only am I at least 30%+ faster while coding, but in general the process is so well oiled that I have near-0 resistance to just jumping in and getting something done. I jump around in code like crazy, can jump to different files instantly no matter where they are (find-file-in-project), do git stuff (magit), have REPL right there in the editor, replace REPL with some code buffer instantly, set up 4-way split panes and kill them in a split-second, etc. etc.
In my opinion, tooling is very important. You want something that makes you a wizard - something that's smooth and FAST.
I once worked with a very experienced gentleman who preferred Notepad to write 3-page-long SQL queries. He knew his craft very well, got the job done, but boy did he take his time :-)
As a Vim user, I consider the whole productivity thing about it quite over-rated. Yes it's efficient, yes it's faster, but in the end, anyone with a decent editor is going to go faster after a while.
The point is comfort. Once vim's mechanics are assimilated, you starts to memorize meaningful sequence of letters, like ci". And those sequences are just words you're typing, so typing code or entering commands is exactly the same thing.
And none of this require going too far frome the home row with your hands. This in my opinion is why Vim is so good :)
I have tried Zen Coding (now called some forgettable name) in several editors, vim, notepad++ and sublime text.
It is much more productive to use it in ST, just because I get immediate feedback. I get the full result in the editor in realtime, just as I'm writing the Zen Coding mantra.
The jump around all folder files in ST? Ctrl-P. It has fast and beautiful fuzzy matching. Do I need to open a file called Module/SuperCalliFractillicious.something? Ctrl-P, mscf, enter. File is opened and the cursor placed wherever it was the last time I edited it. Which could have been months ago.
Git integration? covered in several fronts. Git gutter was first seen in ST.
I do agree that tooling is very important. ST is a serious tool. Do not compare it to notepad.
> I would really love is having my editor, and a couple command/console prompts in the same UI.
OFMs like Far Manager, Midnight Commander or similar might fill that niche. Far does for me, at least and I tend to spend my time editing code either there, in VS or Eclipse, depending on the language and project. But it's more a file manager with an editor (which needs a few plugins to be used for coding) than an editor with a command line.
Every time I read these comparisons I can't help but picture two guys arguing about screwdrivers:
Guy 1: Hey, mine is a flat head, definitely better!
Guy 2: Nah, mine is a Torx, shiny and fancy, definitely superior!!
And these two guys always seem to forget that one works as a carpenter and the other one services electronics. I can't see much rationality in the argument.
I got the point just fine, I just didn't speak to it. You feel that for Vim vs Sublime, one can only be considered superior to the other when context is taken into account, correct?
Well, that's not the case with driver heads. There isn't a serious application that I can think of where slot screw heads would be superior for either carpentry or electronics. Or any discipline, really. Their only benefit is that in low-torque applications a substitute driver can be used (butter knife, coin, etc), but I imagine that is rarely a concern in practice.
If you had gone with any other driver head in your example I wouldn't have been compelled to comment. As is, slot is the worst. It would be the Windows Notepad of the editor space.
If you intend to be a professional programmer for 10 years, 20 years, maybe 40 years, why is it a big deal to spend 2 years becoming adept at an editor? Vim and Emacs are both likely to be lifelong tools that will easily repay the difficult early days.
295 comments
[ 4.2 ms ] story [ 233 ms ] threadNote: j/k lol guys.
Most developers I know now know enough vim to use it in a pinch for editing on remote servers. What I'd really like to see to handle even this edge case is a browser implementation of Sublime. Now that would be cool.
http://icecoder.net/
The only major upside is that Sublime Text might have a 3rd party step in and fix its broken vi handling (someone started to do this with VintageEx).
One of the more underrated features of Sublime Text is the Command Palette. Just by pressing ctrl+shift+p, you can access almost any command, without having to memorize some arcane shortcut key. It is an incredibly powerful feature - one that I really wished Vim had.
BTW, the Ubuntu HUD does the same for any set of menus in a compatible application.
Hit Alt key, access all the menu commands.
Asking a new engineer to work on vim (or emacs or any antiquated editor) would indeed be stupid and I would question any engineer's sanity who would suggest such.
Vim definitely appeals to minimalists and it's non apparent design and GUI makes it sexy. But I totally agree that's it's not worth to learn Vim nowadays and people using Vim in general just want to show that they are some real hackers.
When I was in my 20's and early 30's I rarely thought about optimizing such things. I thought people who obsessed over Vim/Emacs were a bit odd. Now I'm one of the odd ones. I hope you never have a need to resort to such arcane arts, but if you do, Vim and Emacs will be waiting for you.
Switching to an ergonomic mechanical keyboard (kinesis advantage) and a keyboard-heavy workflow (vim) allows me to work as a developer.
I can tell how often I resort to using the mouse each day by the pain when I get home (I have a trackball on my left hand side and a touchpad on my right hand side to try alleviate this), thanks to not using the mouse all day I can often game for a few hours without too much trouble.
This isn't necessary specific to vim, however vim's modality and extremely expressive command language really minimize the amount of movement I need to do for any given action, no more emacs-pinky for me.
Before switching to Vim a few years ago I got a Comfort Keyboard to see if that would help. But after switching to Vim I find that I don't need anything other than a normal keyboard so far. I hope that doesn't change for the foreseeable future.
I hope you continue to find ways to improve your situation. It seems like things just keep getting better for those of us who need to avoid the mouse as much as possible.
As much as I wish you weren't in pain, it is a little comforting to know that there are others in a similar situation.
The main advantage of the kinesis for me is all the buttons around the thumbs and the fact it supports remapping from the device itself, so that whenever I am feeling pain I move keys around to alleviate it (often moving keys away from pinkies and towards the thumbs if I find myself using them often).
I have a windows,alt,ctrl and tab key under each thumb. Shift and backspace under the left, right and space under the right.
On my laptop I have capslock as esc but this doesn't help too much as my pinkies are quite painful to use after a while.
I use dwm, set -o vi for most of my terminals, and pentadactyl in firefox.
Haven't heard of Vimium; I have been looking for a Chrome equivalent as I prefer it as a browser, pentadactyl is nice but it has the issue that it currently doesn't support the use of ctrl-c which drives me insane.
If when you say vim you mean the antiquated relic, the impossibly-steep-learning-curve editor, the maddening modal machine, the most discouraging interface, which infuriates experienced users, confounds new users, and yea, literally takes the mouse from your hands and sets it on fire; if you mean the editor that takes every other editor and stomps them into the floor, shouting all the while, "I am better than you!" as you look on in total despair, then certainly I am against it.
But, if when you say vim you mean the savior of efficiency, the feature-complete friend, the wise teacher, the universal helper, that is there no matter what the task, that asks only for your patience in return for life-long skill, that teaches new lessons right when you think you have mastered it, that frees you from reliance on the IDE and says, "rely only on yourself"; if you mean the tool that becomes a personal, intimate companion to anyone who has the fortitude to let it, then certainly I am for it.
This is my stand. I will not retreat from it. I will not compromise.
(Borrowed from the "If-by-whiskey" speech, delivered by Noah Sweat in 1952. http://en.wikipedia.org/wiki/If-by-whiskey)
I do not have to think about what I'm doing in vim, when it comes to normal text editing.
To be quite honest, getting up to normal-editor level with vim shouldn't take more than a month to become comfortable. Learning to move, yank, paste, and navigate windows is not hard and you really don't have to think about it.
More advanced usage I have to think about, but that's no different than if you had to think about what you were doing in sublime when you clicked search and replace and started typing in a regular expression.
My keyboard mapping of choice is Brief and the way this works for me is I think of a task and my fingers figure out what keys are needed.
On occasion I need do the reverse action, figure out what keys are required for a task and that requires a fair amount of thought.
What I do is think of the task and then as my hands are working I watch them to figure out which keys where used. It’s quite a strange feeling.
https://github.com/henrikpersson/rsub
Second option: Use sshfs and autofs. Works straight at kernel's VFS layer, which is IMHO way saner than any kludges like netrw/rsub/TRAMP/etc.
The problem with Vim is that it is not designed for my shiny MacBook Air keyboard, it can't get benefit from all modifier keys other GUI text editors uses.
I don't know much about computer history, but I believe keyboards that Vim is designed for didn't have any modifier key but Escape. I guess they didn't have Shift too. That's why old programming languages are all uppercase.
Anyway, don't love your technology: http://prog21.dadgum.com/128.html
The point is, all modern keyboards basically have what keyboards have always had (unless you're counting those old Lisp machines or a 5250 for an AS/400 or something) 4 modifier keys.
You can't fire up BBEdit or Sublime Rext on the remote end and get reasonable performance locally unless both ends are on a decent high speed network, mostly due to the need for screen sharing.
No need to rant.
2. People who want to learn vim will use vim.
I've tried many editors before vim, and now I'm solely using vim, I mean, the whole thing about it. The integration with tmux, ssh, working with all the shortcuts and command magics, its community, everything. I realize this is the editor I wanted to use. I can spend hours doing things in terminal, seamlessly with vim, most of the time I didn't produce either good quality or good amount of code, but I enjoyed every minutes of it.
I'm sure people feel the same way about whatever editor that they use now, if they don't, let them pick whatever new editor they wanted to learn. Why all the hate?.
Read :help. I haven't read any books on Vim so I'm not sure if there are any good ones, but you most definitely do not "need" to read one.
"The point of a mouse is to make arbitrary on screen jumps efficient, and it’s very good at doing that. Don’t you ever think you can beat a mouse. Only in very few edge cases will it even matter."
That's kind of ridiculous.
When you edit text, your "jumps" are not arbitrary—they have a structure to them, and Vim lets you express your movement within that structure very efficiently in terms of lines, words, sentences, search, etc.
With a mouse or trackpad, you have to move away from the keyboard, make a movement to the general area you are targeting, then fine-tune your target down to a space between two characters to insert the cursor.
"Pathogen, the first widely used, known, and celebrated path manager making plugin management possible, was released in 2008! Before that, you were encouraged to recursively copy the plugin’s directory into your Vim folder."
And before 2008, Sublime Text was nonexistent. What's your point?
I have used a plethora of plugin systems, and Vundle is the pinnacle of all of them. Simple to install, remove, and update.
"700 hand written lines in my .vimrc, and 45 plugins"
I may have found the problem. Learn to use the editor.
For years I believed that eschewing the mouse was speeding me up. But I recently had the pleasure of working with a fine gentleman, and a SublimeText user, who is an absolute fiend with the mouse. He has considerably more development experience than I, so it is not an unbiased comparison, but I believe his raw editing speed was a bit faster.
This confirmed my suspicion, originally triggered by reading about the Acme[1][2] editor in Plan9, that such a workflow can be quite efficient.
[1] http://en.wikipedia.org/wiki/Acme_(text_editor) [2] http://www.youtube.com/watch?v=Pydckb9ZU8Y
The difference is probably negligible, though.
The way I work in Acme, commands (whether built-in or my own) are presented in front of me for execution, so I edit and highlight and execute them. I don't take time out of thinking about code to think about the magical key combinations that do whatever. So it's more muscle memory to commands on the screen and sight recognition than remembering keystrokes. I do recall that many of my Emacs commands were muscle memory, but the more I wanted to use, the harder it was to remember them all. I lost them quickly when I stopped using emacs. Years from now the commands I used to manipulate files in a given directory will still be there in the guide file, waiting for me to run them without error. (I help this along by directory-specific logging of interesting commands.)
I was especially happy to get away from the hundreds of extra options in the GNU tools userland, which made entire other tools obsolete (e.g., sort -u obsoletes uniq, except when you need to uniq -c or uniq -d). All these options are the enemy of clarity in code, so you can more confidently write portable, straightforward scripts, go back to them later and actually read them.
Adding support for moving the cursor with the arrow keys would not involve a very high amount of complexity. I found that Acme required me too much to just let Rob Pike dictate how I should work rather than providing a tool that I can customize to my habits and my needs.
In any case we should soon have eyeball tracking to move around. and/or leap motion. also when can I simply shout at the screen and get it to do my bidding?
Since we, as programmers, deal with very small targets, using the mouse is not the most efficient way to go.
Some editors allow us to move very quickly to the next opening bracket on the line (Vim's f{ for example) while most editors can't help beyond a certain point (usually the OS's word-by-word jumps). If the only means you have to reach that opening bracket is a dozen presses on the right arrow or the mouse… well, the mouse may have its chances. When you can do f{ the mouse is simply useless.
Also, the motion of the mouse is non-linear: you have typically a fast startup followed by a progressive slowdown until you reach your target. That slowdown happens because the fast startup was done in the general direction of the target and must be adjusted a few times to hit the target accurately.
Another thing to factor is how often you use the mouse in your workflow.
When I do mouse-y tasks (Photoshop, browsing…), the mouse is my primary way too interact with my programs. My left hand is available for hitting modifiers or changing tools while my right hand is almost always on the mouse. In that context, I never loose the pointer and the mouse. Changing from task A to task B with the mouse is easy and costless.
When I do keyboard-y tasks, the keyboard is my primary means of interaction. I can spend a lot of time typing stuff, moving around… without touching the mouse. When I want to use the mouse I usually don't really know exactly where it is — that's a first problem — then, when I grab it, I don't know where the cursor is — second problem — which makes the initial targeting slow and error prone. Once the first steps are dealt with, the limitations in Fitt's law apply.
That's why the mouse is frowned upon among people who use primarily the keyboard.
However, how many people who frowns mouse use knows that you can select a word by double clicking on it, or that you can extend a selection using shift+click, or that nothing scrolls a document as fast as the scrollbar or minimap?
I think that my comment is clear on my position on that "mouse debate": the mouse is an effective interaction device in more than many contexts but there's at least one context where using the mouse is not the most effective thing to do.
Again, the problem is not the mouse itself but the cost of constently switching between it and the keyboard.
The clear win is using a powerful GUI-based editor that has tons of keyboard commands. Bonus points for being on Windows or Linux (i.e., not Mac OS) so you can navigate/BROWSE the menus from the keyboard.
I don't know Sublime myself; I'll have to check it out. For some reason I thought it was Mac-only, but I see that it's cross-platform. My editor-of-choice for years has been Visual Slickedit, but I'm not married to it. I just haven't found anything half as good in years of searching. And I keep trying other editors, too, since there are things I find imperfect about it (the scripting language is usable, for instance, but has it's own syntax and quirks).
In terms of scriptable editors, the Zeus editor is scriptable in Lua, Python, TCL or JavaScript, but it is native to Windows: http://www.zeusedit.com/
Jussi Jumppanen
Author: Zeus IDE
SlickEdit also Just Works with tagging. You put the files into a project, and everything is instantly cross-referenced. "Where is Foo::init() used? No, I don't want Blah::init(), just Foo::init()." SlickEdit, at least SOME of the time, can get that right, and with no configuration of external tools.
Aside from that, I think one of the greatest drawbacks of Slickedit is that it isn't open source, so when things go wrong I can't just fix it. Slickedit IS cross-platform, at least, with native Linux and Mac OS versions, and that ALSO is important to me.
Lua is the Right Answer for scripting, IMO. The rest of the options are actually a liability for me, since it means that if I'm editing someone else's script, I might have to deal with Python, TCL, or JavaScript.
I'm rambling now. I feel like I have an "Editor Manifesto" in my head that wants to get out, but I don't have time right now to do it justice. I'll take another look at Zeus when I get a chance, just as I'll take another look at Sublime and the rest. It's been years since I've looked, so I'll take another glance at it.
In any case, I prefer to use the F keys as standard functions keys.
If you're telling me I can hit Ctrl-F2, then that's at least a step in the right direction. Thing is, it's several steps behind where I would be on Windows (or most Linux desktops), because I can just hit Alt-F and it opens the file menu, or Alt-T for the tools menu, or what-have-you.
Still, it's better than nothing. Thanks.
http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
http://www.asktog.com/TOI/toi22KeyboardVMouse2.html
http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.htm...
[If you think this is incorrect, providing links to scientific evidence is more productive than downvoting or stating that your own subjective experience is different.]
EDIT: not sure why the downvotes—should I have said "faster FOR ME"? Anyways, hi haters.
Try coding in an editor, any editor, for 8, 9, 12 hours a day and see if you don't start forgetting the keyboard shortcuts because they become reflexive. Vi and Emacs are just hyperdesigned to enhance this effect.
EDIT: And I don't care that you link to Bruce Tognazzini, a GUI designer, when millennia of musicians have known that they don't think about what combinations of fingers they press to get an F#, they just play a glissando with an F# in the middle.
I think your last sentence supports Sublime Text even more than it supports Vi(m).
1. Start the graphical version, i.e. gvim, MacVim, or any version with drop-down menus.
2. Press 'i' to enter "Insert mode". Now just use it like any other text editor.
3. Use the menus. Note the equivalent commands (which are listed in the menus). When you want to use those commands, press ESC to switch to command mode, then enter the commands, then press 'i' again to go back to insert mode.
That's it. Modern vim has one of the smoothest learning curves of all software.
This ^^, say no more.
Learn to use the editor? Are you just editing your visual basic files or what?
Edit: if you could also point out which of my vimrc lines are fighting against the vim way and demonstrate that I don't know how to use my editor, that would be super cool.
You just have to learn it, period. It seems daunting but it's not as hard as some people make you believe it is. I admit vim's plugin system is bad and vim doesn't have a nice API subl has for extensions, but there are experts who write great vim plugins so you don't have to and worse comes to worse, you don't have to load up your vim with plugins to be productive. I have another co-worker who uses vim and is very productive and does not use any plugin at all.
Finally, if you're a new developer, don't listen to the op. Spend a few weeks to learn vim, or emacs for that matter, and you'll be so much better off in the long run.
I spent almost 3 years working exclusively in vi. I got used to it enough to handcraft my own .vimrc file, use multiple buffers, integrate with ctags, etc etc. I think I was reasonably proficient in vim at that time.
At around that time, I did a coding project with a friend who was an emacs user and when I say him code I thought to myself "Wow, he flies!". That day I dumped vi and went back to emacs. I've never looked back.
Emacs' macros, different modes, integration, shells, etc, etc, let you deal with all sorts of systems in a pleasant way. Learning emacs is a much better investment than vim.
Just hit 1.0 as well.
Side note: I think I'd love emacs if I hadn't learned vim first. Having a real programming language (elisp) for configuration and extension is nice.
Btw, not that I have something against programmers who use the mouse in their editor. Just don't say it's as fast because it's not.
>You can do EVERYTHING without the mouse
What are you using to edit text with? The power of thought?
Want to rename an identifier? Double click it with the right hand, Ctrl-<replace> with the left, tab with left to proper position in dialog while right hand is returning to home, type replacement, hit enter a few times.
Adding a prefix to a bunch of strings? Click-drag to select the prefix while hitting Ctrl-C (stretching the pinky to reach the Ctrl takes about as much time as the entire click-drag), click click click on all the places you need it to go, timing the clicks with Ctrl-V on the left hand, scrolling with the wheel as needed. Very, very fast.
I suppose that describing it doesn't do it justice; I certainly wouldn't believe it if I hadn't seen it with my own eyes repeatedly.
But nevertheless, I would happily take up his challenge: let's find a word that is in the document, but not currently on-screen - hardly an 'edge case', more like 'routine task'. Good luck at winning that one, mouseketeer!
Another great one that sees regular use at my fingers is ci' or ci" - again, hardly an edge case, and blazingly faster than selecting the characters just right with the mouse.
I have no problem with using the mouse for certain things, but blanket statements like the quoted one are rarely anything but wrong.
Where I find a mouse useful is when I want "that loop which I suspect is misbehaving. That one which adds a new member to all arrays". There a quick flick of the mouse-wheel, and then fine positioning of the mouse cursor I find gets me to my location faster.
Even when the loop is on the screen, maybe 35 lines up, I have to either do a binary-search style jump with the keyboard, or with the mouse just click on it.
Also, looking for a particular word is easy when there is only one occurrence of it, or you want the next occurrence. A mouse might still be useful when there are many occurrences of a variable and you want (for example) one somewhere near the end.
Perhaps vimmers tend to keep better track of where everything is to make it easier to "hard jump" to, while mousers tend to keep a more ad-hoc overall view, so they know approximately where to scroll to?
Jumping to a loop on the screen is as easy as viewing the line the loop is on, then hitting colon+line number (e.g. ":68"). This might be what you're referring to with a "hard jump".
I also use the "number+command" shortcuts quite a bit. If you want to jump up/down 20 lines (or 2000), then "2000k" or "2000j" will move the cursor up 2000 lines or down 2000 lines. Also a hard jump.
But to find an occurrence of a word at the end of the file, the typical search sequence is the following: 1) :$ - this jumps to the end of the file ($ is a common regex meaning 'end of', the same way that '^' means beginning of) 2) ?word - this does a backwards search for the word. this is at the bottom of the file, searching upwards 3) n - this jumps to the next occurrence of the word
So thats like 5 keystrokes not including typing in the word. Jumping around and viewing files really is neat with vi/vim.
Hell, I even did VIM Adventures. I like a lot of the hotkeys and shortcuts for stuff, but its weird.
I am much happier and productive in IntelliJ and Sublime. and if I do something in command-line. Its Nano that I use.
I think its mostly the hotkeys and the lame "insert" and "command" mode seperation. I want to be in both modes. Hence I like the hotkeys on most IDEs.
a) Never thought vim was that hard to learn (and I first learned it when I was a teenager and nobody helped me. I switched when someone on a MUD made fun of me for using pico.)
and
b) Thinks vanilla vim works just fine. Seriously my vimrc is like 10 lines long and I don't even have it on every server I work on. I don't bother with any plugins. I don't need vim integrated with git, I don't need it to do anything except let me edit text efficiently.
I dunno maybe I'm crazy.
EDIT:
I also often feel like I'm alone in not treating what tools (including text editor) I use like it's a religion. I don't care if anybody else uses vim or not. People should use what they wanna use, what do I care?
These kinds of rants make me wonder what kind of medication the OP stopped taking. If he hates vim so much stop using it. It's clearly causing him a lot of misery.
Vim is good at editing text, is extremely portable, and works great with a partner in crime like tmux.
I have used vim for 12+ years, and the complexity of his setup makes me a bit dizzy.
Sublime and Emacs are joys to extend versus Vim, that doesn't mean it can't be done, just that it is tough.
C-a and C-e and a dozen of others are there, yes, but good luck if you think you can use M-%, M-h or whatever is the Emacs equivalent of Vim's text-objects and motions (which is what the parent was thinking about).
I'm pretty sure as a teenager is the best time to learn such tools. :P
I started with gvim, then eventually got comfortable. I never felt like I had to cram down vim facts. I just took them as they came.
Totally agree regarding b). I like to be able to jump on a random machine and NOT miss overcomplicated .*rc configuration. My .vimrc is 11 lines long, including 3 comment lines and to blank lines....
Vim is my text-editor of choice, but it took me a lot of time and effort to customise it to make it more suitable for writing prose.
E.g. the fact that it scrolls by logical lines rather than screen lines (note I that I said scrolls. I'm aware that you can navigate by screen lines by using gj and gk). The way this makes the text scroll by unpredictable amounts when you have paragraphs of text is pretty jarring. You can hack around that by getting the text to auto-format and break lines up into screen lines, but there's all sorts of niggles with that (and FWIW, it causes some of its own problems, such as making it harder to search for phrases, because words may no longer be separated by just spaces but also possibly linebreaks).
What else would you find missing for a writing workflow?
For me this is primarily my planning/diary file and the phd documents I'm writing.
- formatoptions+=a: auto-format as you insert text, which means it will (basically) automatically insert a newline once you've typed 'textwidth' number of characters on your line. it will insert a newline while you are typing.
- formatoptions+=w: this isn't necessary, but it has an effect on the way the auto-formatting is done. i find the 'w' options more convenient. With 'w', a linebreak means a new paragraph, unless trailing whitespace at end of line. It means that the 'a' option doesn't auto join lines separated by a linebreak.
- if you're not familiar with Vim's autocmds, what they're doing in the above definitions is setting those options for any text files that are opened (and only text files).
I've also setup Taglist http://www.vim.org/scripts/script.php?script_id=273 so that it can show a listing of the markdown headings in my document.
[EDIT: added brief explanation of autocmds]
I agree with the author - I'd also recommend Sublime Text 2 - but vim fills a great niche - when you only have a telnet terminal, so it's always good to know the basics.
Right tool, right job, etc.
Dear God. We're talking about a text editor.
The OP has a really "sane" take on things imho (yes, it's incredibly opinionated, but it's blog post featured on HN, not a SO question someone like you can close in minute :) - and I'm glad he bothered to write it, as I'd probably just send the link to it to any newbies asking me about "the magical vim" instead of bothering to tell them what I think) and he's right on one thing: vim will not increase the productivity of a new user. The actual productivity increase will only happen months later (basically too late to worth it), and it will not matter that much because 90% of the time spent coding is actually spent either:
(1) plainly writing code (no advanced editor functionality helps here, Notepad++ is basically good enough!),
(2) making simple edits to code (again, more editor functionality doesn't really help because 90% of the time spend editing code it actually spent thinking about what to edit, not actually pressing the keys)
(3) reading code,
(4) exploring codebases (the only thing helpful at this is a full featured IDE - it just takes too much work to turn vim in to something like this, and you'll just end up with something mostly matching Netbeans feature-wise, so you could just as well install Netbeans or something else better for your language/framework in 5min and spend 1h to really learn how to use it),
(5) debugging (again, the only thing that could, for some, including me, increase productivity, is a full-fledged graphical debugger).
...and if you need to improve that last 10%, then you are far from a beginner at anything, eg. you are not the person that vim tends to be recommended to nowadays.
And the OP also expressed why I like ST so much: "To code in Vim, you have to keep Vim in your head just as much as the code that you’re editing. You have to constantly think about what you’re doing." - at most (not all) things ST beautifully follows the "don't make me think" principle: eg. arbitrary multiple cursors (no other IDE or editor besides Notedpad++ has them yet, no matter how many users requested this for JetBrain IDEs for example), that just let you "edit without thinking", keeping the code in your working memory instead of the sequence of search and replace commands.
But all that said, I absolutely love vim's keybindings and modal editing concept, so I tend to enable vim keybindings or install a vim-emulator plugin on most IDEs and editors I end up using because it also spares you of having to commit the different shortcuts that every other IDE and editor uses to "muscle memory". I see vim like more like an uptional UI/X layer that should be addable to any decent editor or IDE to enable experts to improve their 10%. Fortunately Sublime text has such a "layer" so OP's post is kind of valid.
Emacs support for multiple cursors is also available: https://github.com/magnars/multiple-cursors.el
Or, when you have a nice set of lined up/indented declarations, it's trivial to just right-click+SHIFT and drag a cursor before every line and start typing.
It is absolutely incorrect that you have to 'keep Vim in your head just as much as the code that you're editing' unless you have not learned Vim at all. The reason you don't (constantly) have to think in ST or notepad++ is because you have already learned that editing paradigm. Although, that editing paradigm IS more obtrusive than vim's. It's abundantly clear that you do NOT understand vim's keybindings and modal editing concept, if you constantly think about vim.
vim has code exploration tools integrated: they just have funny names like ctags, grep, cscope. If you want them. You can also just use separate tools for browsing vs. editing, with no obvious productivity loss.
The productivity impact of having the debugger in your editor process cannot be a big deal, and it's pretty weird to hear that this is essential right after you stress that notepad++ is good enough. Which one is it?
If the point is that you spend most of your time writing, editing and reading code and otherwise the only advantages are in heavy-duty tools not present in ST, then the implication isn't that it's "sane" to reject vim, the implication is that it doesn't make any difference what you use.
When we're talking about a text editor for programmers, I don't need it to be usable by somebody who doesn't grasp the domain to begin with. I'll gladly give up some UI sugar because in this context a modal interface is exactly what makes me so productive with it and partitions the complexity into composable chunks that are easily reasoned about.
Well, I do use vim, so I can't really hate it, can I? :) ...it's just the thing that some things should just be plain and simple imho, code editing should not be a "domain" in itself and one should rather learn unrelated new things than bother tweaking that last 10% ...it's just a matter of preference and take on life, some strive for "mastery" at something and work on that last 10% to get an edge, others don't bother to achieve "mastery" at one thing but prefer to explore more things and get that edge by "perspective shifting" or "thinking more outside the box". I bothered to learn vim out of "exploratory curiosity", because I found the concept of such an interface interesting. But though interesting, I don't consider it a good idea anymore - if you give people a tool to manage complexity, they will take advantage and add more of it, for very little benefit.
I guess I look at vim as less an interface that a user needs to become familiar with and more of a language that one learns to manipulate text. For example, I don't think the same design principles that go into maximizing conversions on a website necessarily apply to learning Russian. The tradeoffs are different, as is the payoff.
What do you mean by "arbitrary multiple cursors"? Do you mean the thing that all Scintilla-using applications (which Notepad++ happen to be one of) have?
Oh, you mean like this?
http://emacsrocks.com/e13.html
https://github.com/emacsmirror/multiple-cursors
I have the same setup as you - vanilla vim, barely customized and the development pace is hardly any slower than when I use Visual Studio with all its auto-completion, deep syntax parsing, etc. I saw Jonathan Blow (of Braid) saying that auto-completion and better debugging support is a deal-breaks for him, but everyone`s work pattern is different and I`ve seen plenty of cases where people using vim accomplished far more and faster than those with fancy editors. Tools are important, but they are secondary.
Sometime, Vim user tend to make their Vim into full-fledged IDE, like completion, file-browser, etc. That things I though, makes Vim user gone insane.
Seriously, Vim just for editing text, nothing more, nothing more.
I use plain vi[m] for several reasons but mainly because I used to visit customer sites all the time and have to use their environments. If I need to edit a whole bunch of files I needed to do it with what the customer has installed, and the bare minimum to rely on is plain old vi.
My .vimrc (if it even exists) contains:-
That's it, and I generate that by hand whenever the syntax highlighting begins to annoy me if it isn't set. I've never used or even looked at a vim plugin.Of course plain old vi has its limitations but I know what they are and have pretty good ways of doing anything else I need to do.
When I started learning vim all I knew were the command modes and how to move around using hjkl. Slowly over time I added more commands.
Later I've developed a wrist pain and got interested in ergonomics. One thing I've noticed was how badly the arrow keys are positioned and how "unhealthy" it is to use a mouse with a right hand (numpad shifts the position of a mouse too far right). And then I started thinking about minimising use of a mouse and arrow keys. This led to the rediscovering of vim.
It was surprisingly easy to learn and later surprisingly hard to use other editors.
a) Never thought vim was that hard to learn (and I first learned it when I was a teenager and nobody helped me. I switched when someone on a MUD made fun of me for using pico.)
Yeah, I was rocking vi in high school, and I'm no genius, I had an ULTRIX vi reference card. The article's assertion that you have to read any books to use vim effectively is bullshit. As for the religion part, that usually comes in when someone tries to dictate what editor other people will use. I don't give a shit if someone on my project uses Eclipse or MSVS, just don't take my Emacs away.
Since he mentioned indenting, let me ask: how do you properly indent JSON or XML in Sublime Text 2 out of the box?
I've tried setting the appropriate syntax, selecting all text, then doing Edit->Line->Reindent but it gives half-broken results. Is that intentional, or am I doing something wrong?
Also, is there a way to quickly select all instances of currently selected identifier within the local scope? Selecting one _highlights_ all other local scope instances, but how do I make it select them all with one action?
If so, what can be done to make it more visible?
Isn't it a pretty common thing to rename local variables? I'm not sure why it's not a readily available feature.
You get one cursor for each instance, so you can select and then edit all at the same time.
I'm sure it is a readily available feature. In fact, I use it every day several times since I first installed ST.
:set tw=10000 | norm gggQG
Tools are a highly personal topic, what works for one person doesn't necessarily work for another.
My advice is to try using one and only one new tool a week. By the end of a month you'll have a good idea of what your own preferences are and the relative strengths/weaknesses of others.
With editors, that'd probably be a gamut of vim, emacs, Sublime, Eclipse, and Visual Studio Express. If you're a Java developer, IntelliJ is worth looking at.
> [...] I’m going to go search for how to do it. I’m probably going to learn something in the process. At year 4 of Vimming.
I don't get why this is a bad thing. I've been programming for decades and still learn new stuff every week.
It should be noted that vim and emacs definitely appeals more to the maximizer over satisficer personality:
https://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_Mor...
'format' is not a vim option. Perhaps he meant filetype?
2. By the end of month 1-2, vim had become completely second nature. I did stuff without thinking. Actually, thinking about what I was doing started to confuse me.
3. Sure we all spend lots of time thinking, but I also often find myself cranking out code and vim is quite amazing for that.
4. I ended up switching to emacs because a) I like learning about tools (see #1) b) emacs gives you a more IDE-like experience c) while retaining 90% of vim's editing power d) and in general has the similar "become an editor expert" philosophy to optimizing editing workflow
I haven't used sublime, but I'm quite fond of editors that are keyboard-only (especially for jumping around, etc.), cross-platform, have stood the test of time and have endless extensibility.
edit: I have customized both vim and emacs to crazy depths. There was a time when just as I started to code, I'd say "why can't I do this [blah] drudgery automatically?" and end up writing an emacs function to do it :-)
Sublime is really pretty, and has great functionality out of the box.
Ultimately, vi/vim's contribution is the modal editing method (and derived things like motions), which can be transplanted to any other IDE or editor that cares to support it. But for the fundamendals - editing and switching between files - I've so far found vim to be the cleanest, most natural vim.
[1]: http://jelv.is/emacs-blackboard.png
Also, have you tried Evil? Apparently it's a very good Vim-emulation mode for Emacs, highly recommended over Viper.
I haven't tried Evil, in my last emacs phase it wasn't mature yet IIRC - maybe I should give that a go and see if it tips the balance yet again.
[1]: https://github.com/jonathanchu/emacs-powerline/blob/master/p...
Obligatory vim can be pretty too, and I am happy with how mine looks.
http://i.imgur.com/ZC2xDxH.png
On a related note, I like how my terminal vim looks better than how the GUI looks. I don't use emacs much, but same goes for emacs.
My screenshot doesn't have custom status bar shapes. GP does. Anyway, for that, you need powerline(available for both vim and emacs).
My color theme is ir_black https://github.com/wgibbs/vim-irblack If you are using it in terminal, you also need to set up ir_black theme for the terminal.
Not sure what that means
> even after having in aggregate spent many days customizing it
Do your work and if you find you can add something to your ~/.emacs then do
> Vim feels cleaner and less annoying,
I cannot empathise with that. Model editing is awful. I feel like i should have a foot pedal to actually toggle it
/oldest debate in the world
I also appreciate what an actual IDE offers in those environments. I use VS (C#) and WebStorm (NodeJS) more than anything lately.. and wouldn't give them up. I'm impressed when I see people get work done in VIM... I just don't think that way, and don't manage to memorize a bunch of hotkeys I don't use at least 10 times a day. Hard enough keeping the step keys for debugging in different IDEs straight, let alone, more esoteric things.
In my opinion, tooling is very important. You want something that makes you a wizard - something that's smooth and FAST.
I once worked with a very experienced gentleman who preferred Notepad to write 3-page-long SQL queries. He knew his craft very well, got the job done, but boy did he take his time :-)
As a Vim user, I consider the whole productivity thing about it quite over-rated. Yes it's efficient, yes it's faster, but in the end, anyone with a decent editor is going to go faster after a while.
The point is comfort. Once vim's mechanics are assimilated, you starts to memorize meaningful sequence of letters, like ci". And those sequences are just words you're typing, so typing code or entering commands is exactly the same thing.
And none of this require going too far frome the home row with your hands. This in my opinion is why Vim is so good :)
It is much more productive to use it in ST, just because I get immediate feedback. I get the full result in the editor in realtime, just as I'm writing the Zen Coding mantra.
The jump around all folder files in ST? Ctrl-P. It has fast and beautiful fuzzy matching. Do I need to open a file called Module/SuperCalliFractillicious.something? Ctrl-P, mscf, enter. File is opened and the cursor placed wherever it was the last time I edited it. Which could have been months ago.
Git integration? covered in several fronts. Git gutter was first seen in ST.
I do agree that tooling is very important. ST is a serious tool. Do not compare it to notepad.
OFMs like Far Manager, Midnight Commander or similar might fill that niche. Far does for me, at least and I tend to spend my time editing code either there, in VS or Eclipse, depending on the language and project. But it's more a file manager with an editor (which needs a few plugins to be used for coding) than an editor with a command line.
Guy 1: Hey, mine is a flat head, definitely better! Guy 2: Nah, mine is a Torx, shiny and fancy, definitely superior!!
And these two guys always seem to forget that one works as a carpenter and the other one services electronics. I can't see much rationality in the argument.
https://en.wikipedia.org/wiki/List_of_screw_drives#Robertson
https://en.wikipedia.org/wiki/List_of_screw_drives#Phillips
Well, that's not the case with driver heads. There isn't a serious application that I can think of where slot screw heads would be superior for either carpentry or electronics. Or any discipline, really. Their only benefit is that in low-torque applications a substitute driver can be used (butter knife, coin, etc), but I imagine that is rarely a concern in practice.
If you had gone with any other driver head in your example I wouldn't have been compelled to comment. As is, slot is the worst. It would be the Windows Notepad of the editor space.