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.
"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.
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.
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?
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.
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).
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.]
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.
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 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.
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 :-)
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.
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.
Almost anybody who associates great programming with things like super keyboarding skills and muscle memory is unfortunately degrading the status of programming to mere typing.
What is it that is so distracting and pulling you out of your zen when you use a mouse? Seriously you type so fast and code at the speed of thought that a little glitch here is like making a mistake with a Formula 1 car in the Monaco Grand Prix?
Let me tell you how real work happens and how productive people work. I am currently working with a very senior electronics guy in the night for some side projects. Watching him work shows me the path on how we programmers should be working. He will first build the base PCB with all his reusable designs and additional ones reading the documentation I rarely saw him Google anything in the past 15 days. If he has to ever get down to googling its generally to find some data sheet. Once that is done, he gets the components and meticulously builds the entire circuit on the PCB module by module. Every time he builds the module he tests if the inputs and outputs to it are as he designed on the PCB. It took a well whole month with each sitting spanning hours to get the whole PCB working. When he was done, the entire PCB worked like magic. The manufactured one's too. And there wasn't a single problem/bug. It was so spotlessly done. It looked like art work.
Yet the pace at which he solders, or used the CRO or multimeter hardly matters or is even relevant.
And yes, he hardly rushes or goes in a rash break neck speed in doing anything. So here is what I learned. Firstly learn to define the problem correctly, break the problem and establish a clear understanding of inputs and outputs to each module. Read documentation get a clear idea as to what it is done. Spend long hours trying to build/test each module. If possible automate testing(if its software). Spend time integrating.
Go slow, the biggest productivity leaks are not in going slow. Go slow but go steady. The biggest productivity problems are in problem definition, solution clarity, distraction and procrastination. For us programmers, let us be frank. Most of us don't RTFM. We jump to googling and then go down the time sink and end up reading all sorts of articles achieving nothing at the end of the day.
If possible work things out on the paper. Do use stuff like Mind Map for test cases. Learn to work things on the paper and by reading documentation. Learn good debugging tools, sound programming practices etc.
That is what counts guys. Not optimizing the 1 second delay needed to reach the mouse. That's not even relevant in the broad spectrum of things.
> Seriously you type so fast and code at the speed of thought that a little glitch here is like making a mistake with a Formula 1 car in the Monaco Grand Prix?
Please, don't take it to the other extreme.
The way I use vim, I still use arrow keys instead of hjkl. I usually don't do 8k or 3j. Yet daW, cs"', cit, /foo<CR>whateveroperationnn.nnn.n., /bar<CR>qawhateverbutmorecomplexqn@ann@a are part of my daily routine†.
Clicking around or moving with arrow keys to operate on well defined text objects feels like hunt-and-peck typing, while the argument is that the only true way to vim is knowing it, similar to touch typing. Yet between hunt-and-peck and touch typing, there's a continuous world.
I type at a reasonable speed, and I use vim at a reasonable speed. I'm not aiming for purity, I'm aiming for usefulness.
In general, Sublime Text does a vast and extensible yet at any given point in time fixed number of things well, while vim allows for composability, and hence even with a default setup and few things known, a great deal can be done already. This is what empowers me, not the home row touch typing stuff, not the navigation speed, but the quality of the dialog I can have with the editor.
† I know about multi-cursors in Sublime Text, and Ctrl+D, but Ctrl+D doesn't allow you to skip, and the whatever_operation you want may or may not operate on the search itself (which could actually be an ack search), and can operate on objects ST doesn't even know about. This allows me to do free-form refactoring without relying on fixed-form refactoring routines and plugins (i.e not just a glorified search and replace).
Let me tell you how real work happens and how productive people work.
Thanks for condescending to all us unproductive children who obviously have never done any "real" work.
<long description of PCB design with iteration and unit testing snipped>
Guess what? That's called iterative design, and some very quality software is made the same way. It also has nothing whatsoever to do with arguing against using proper tools.
Here's a question: if your EE had to stop to deal with some clumsy tool (say, a soldering iron that was too big or had a badly designed handle), how badly would that impact his workflow? That's what people are talking about when they say that using the mouse when editing code (a purely textual medium, I might add) is a cache miss.
What you're missing is that hardware documentation isn't the afterthought that it is in software. That hardware documentation is as much the product as the PCB - because without that documentation, the PCB is useless. And every time the board gets rev'd, so does the documentation (which is rare in software) because if it doesn't, then people can't take advantage of the rev.
It is true that so many of us in software don't RTFM, and I am guilty of that, but it's also true that the FM is often out of date, incomplete, doesn't carry the edge cases, and is often written by a reluctant author inexperienced in writing good copy.
Apart from that, 'go slow' is missing the point a bit. It's not the 'lack of turbo speed' that the mouse is creating problems from, it's the context switching. 'Go slow, steady, and thoughtful' is fine, but the less context switching you have, the more attention you can spend on your task.
Once you have learned to do without the mouse and the arrow keys, it is actively annoying to be FORCED to do that additional motion. This is a matter of ergonomics. Maybe you don't care about the ergonomics of your tools. Using a tool with poor ergonomics is not rationalized by pointing out that you should read and think about what you're doing.
You have no right to condescend to tell others how 'real work happens' and how 'productive people' work, as if you were the only real productive worker in the room because everyone else is using a stupid editor rather than the mouse. Using the mouse doesn't make you a Real Programmer more than other people.
That's all true, but I find when the heavens open and the True Path to implementation shines down upon me, being able to get thought onto disk at roughly the speed I think is important, as is knowing my editor well enough to let me manipulate my code in much the same way I'm manipulating the abstract representation I'm thinking about.
In this instance I'm talking about vim, but it doesn't matter, being able to operate on code in a context that matches the way you're thinking about it is invaluable in my opinion.
That said, I felt this was a bit over the top. While I totally think that this pays dividends, I don't think it enough to write a novella like he has.
Well you get to a point where reaching for the mouse does get annoying. And it does happen, when reaching for the mouse distracts you from your "zen" state.
> When he was done, the entire PCB worked like magic. The manufactured one's too. And there wasn't a single problem/bug. It was so spotlessly done. It looked like art work.
Being bug free is nice, but not really the general case. I agree however that PCBs do need fewer iterations than software to become practically bug free.
I am unsure whether, in the general case, this is due to the quality of the people doing PCB design or due to the quality of the PCB design process (and associated tooling).
Another point is that in PCB design, there is (from my limited experience) a much stronger correlation between quality of the design and the quality of the implementation than in software projects. I attribute this to the lack of hand-off between the design and implementation stages, i.e. in PCB design the designer of the circuit is usually (not always) also involved in the routing process.
I was an Electronics Engineer in my past and never even knew there was a fast lane for making things, until I moved to mainstream programming. The above process of modular "tinkering" in electronics design is perhaps the only way to go if you are building from scratch.
In fact, there isn't anything so distracting and pulling you out of your zen when you use a mouse: that's precisely why the keyboard feels faster (you get lost in thought about what commands to use that you forget the time it takes) while the mouse is, in fact, faster. Ask Bruce Tognazzini.
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.
The area where sublime really wins for me is discoverability. Say I'm writing some markdown and I decide I want to preview it in the browser. A short key combo opens the command palette, I type install package, hit return, type markdown, see that there's a plugin called markdown preview, down arrow and return and it's installed in a couple of seconds. I open the command palette again, type markdown preview, hit return and it's open in my browser. Follow these steps and it will take you maybe 10 seconds or so. Everything's happened without leaving the keyboard and you haven't had to learn any key combos. If you find yourself using a command a lot then you can assign a key combo.
That was just an example, pretty much everything happens this way in sublime. It can all be done by searching commands from the keyboard. The command matching is fuzzy so you can actually figure out the 2 or 3 letters that bring up the command you want and you've got yourself a key combo.
It's this discoverability that makes sublime a joy to use. With vim I find I'm constantly googling how to do things. With sublime learning how to do something usually happens in the editor, thanks to the command bar.
As far as discoverability goes, I think it's hard to beat Emacs, once you figure out what's going on.
The big step is to start using it like a terminal, and Alt-x (M-x) is the way to begin this...
Everything is Tab completable, and fuzzy matched, granted the lexicon is a little different, but it's not very difficult if you're prepared to read a bit.
The fact that you can type:
M-x describe-function
And the get docs for any function in Emacs is really amazing, and something that completely reveals its true nature, Emacs is a huge library of lisp functions...
And after 30 years or so huge really does mean huge.
So frankly, forget all about Sublime and learn Emacs, it doesn't demand a Vim modal operating mode (but it'll provide one if you want it) it doesn't berate you if you want to use the mouse.
It has undergone a huge amount of recent development too, and new packages are being released every day, thanks to elpa / package.el
With emacs, I type "M-x pai", which for me autocompletes to "package-install", and hit enter.
Then I type "mark", and from the completions see that there is a markdown mode I can install. Then I hit enter, and enjoy a new markdown mode!
I use emacs - I don't pretend it's the best thing ever. Vim does seem more conceptually pure, and Emacs is essentially an operating system.
But, goddamn, sometimes you just want to sand-blast that soup cracker. I learned Emacs and I have never had to learn anything else, because of the "M-x butterfly effect."
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:
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.
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 do use the mentioned javascript-vim plugin. However, majority of the plugins I install are because I'm simply one short "Bundle 'user/repo'" away from trying out something I may choose to use. If I was to purposely cut down my number plugins, I probably would only keep minibufexpl and language specfics. The most important vim plugins are those that are simply improvements of basic vim functionality that are more aware of language specifics (i.e. javascript-vim, erlvim). Plugins like NERDTree look nice, but do I actually use them in practice? Not really. I barely use even use ctrl+p: most of the time using :e and tabbing my way to victory is quick enough to be a moot point.
There are costs and benefits to using any editor. I've spent a large amount of my life ssh'd into remote boxes from a Windows machine. It was pretty natural for me to pick up the most common and still powerful command line editor available. I was born into a generation of kids more comfortable using 'WASD' than walking around in real life; it wasn't difficult to get used to hjkl quickly. I don't really consider there to be a learning curve more than 'it isn't obvious how to do things unless you read documentation first' which is actually to be expected. Most of us won't work with a programming language until we've read a book on it and sufficiently experimented on our own. Programming languages are a tool. A text editor is a tool. A similar learning curve seems fair to me.
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?.
These articles are just idiotic. Mouse as fast as the keyboard except a 'few edge cases'? Get out of here.
Vim destroys using a mouse every day of the week, and unless the highest skillset you've learned is fingerpainting, it's not that hard. Sit down for 2 days, stop being a bitch, learn the keybindings, and you're good.
For that matter, text selection in general is often better with a mouse.. I'll go either way (sometimes mouse, others keyboard) but I much prefer a gui editor/ide over console UI... when I am remote, I prefer nano, just get it done/save/out.
Using the keyboard seems faster than using a mouse to move the cursor because you're thinking so hard about what to do with the keyboard that you forget the time it takes to get what you want accomplished, but using the keyboard is objectively, measurably slower than using the mouse for the same task; in other words, using the mouse is actually proven to be faster for cursor movement overall. You're just fooled by your subjective impression.
You've just invalidated your argument by implying you need to think 'hard' about it. I certainly don't have to think about it. The entire point is the make everything 100% muscle memory.
Every time a vim vs sublime article comes out, all the failed vim users who tried for 2 hours come out of the woodwork to comfort their own shortcomings on not following through with a tool that objectively blows away a single mode editor.
You can't deny it, it just cant be done. The one exception is if you're a slow typer. By typing close to 110wpm I can type /ex<cr>vi" even before your fat meat sticks reach the mouse, and I've already accomplished it, pasted it, and am moving it on while youre fighting with putting the cursor right between the e and the "
The "hard" 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. Read the article. 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.
Seriously, use vim, sublime, emacs.. if smearing shit on the walls can be transcribed into text do that.
I do not care.
And neither should you.
It's about getting the job done. Use whatever tools you need to do that. I use vim, and sometimes I'll open sublime for browsing code... does any of that matter? No. I get shit done. That's what matters.
The problem is that people will and do argue vehemently against your choice if you even mention what editor you use, as if it affects them personally.
I thank you for being one of the people confident and secure enough to not care, but sadly, not everyone is like you.
And at some point you have to say "Enough! This is why I made my choice. This is what I believe. Deal with it." Sometimes you have to defend yourself. Not against you, personally, richardlblair, but against people much more annoying and persistent than you.
You are exactly and completely correct, but not everyone has the provenance to be so well balanced, particularly on the Greater Internet.
I think it's a sure sign that some ham-fisted buffoonery is afoot when a company mandates what text editor or IDE a programmer should use. But I'm thankful for those big red flags that signal to me that I would not be happy at this company.
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.
The important takeaway lesson from all this is that, because this guy says a tool you use is bad, it means you, yourself are bad. And as that is a personal insult to your integrity it is of vital importance that you vehemently argue against it regardless of its intrinsic merits.
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.
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.
... 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.
Never really got that anti-mouse sentiment anyway. There are alot of great programmers that use the mouse alot and why the heck not ? I like to use key-bindings wherever appropriate, but there are things which are just plain faster by just clicking. A good combination of both is optimal imo.
Which is why i cringe when i see all these new "vim-mode" plugins for everything from IDEs to browsers to email clients.
>Most novice programmers can click on a character on screen faster than an expert Vimmer can type 20jFp; or LkEEE or /word<cr> or any other nasty way Vimmers have to use because of our archaic, ingrained keystrokes.
Seriously. It is becomes super productive once you realize you can just use a mouse for things you have trouble remembering (resizing windows was one that I always look in the docs for). Then one day you realize you can use a mouse with vim IN THE CONSOLE. On that day you reach enlightenment.
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.
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.
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.
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).
Interesting article. I accept that the seeming overstatement of "about two years ... [to] be proficient" differs case by case and may be an average or worst case scenario. Still, the next argument that "The argument that Vim is more efficient is dubious and untestable" because "developers are commonly on machines where the trackpad is a micro-hand movement away" seems to miss the critical point that moving away from the keyboard tends to break trains of thought, at least for me and other programmers I know. This is critical because it takes a while to load problems and solutions into your head. It's like building a house of cards. Looking for the mouse cursor slows down that building tremendously.
In the next article : "Buy a lot of software and don't learn programming. It's hard, and after four years, I still can't write anything someone else didn't do better !"
Not only I can confirm that after 7 years of vim, I feel really more productive than when I use any "intuitive" editor, but now I've remap all my window management (either X or tmux) to similar mapping.
One point I can agree, though : vimscript is a real pain in the ass, which defeats what Bram Moolenaar say should be our process - detect repetition and automatize it seamlessly. [1] It will only be empowered when we'll have a full featured language to do so.
> Vim: The Editor You Need To Read (At Least) Two Books On To Use Well
Seriously? I was one of the very early adopters of ST2 (befor net.tuts wrote about it), and configured pretty much everything. I switched to Vim maybe two months ago, and I was just as productive with Vim three weeks after switching.
I still learn about Vim features, and it will me take ages to really know it well, but it's seriously not that hard to learn Vim. The first one or two weeks are hard, but once you got the basic concepts, it's really easy.
Switching to Vim was completely worth it. I way prefer VimL over ST's JSON settings, and I'm generally faster at editing text.
However, Sublime Text is a great editor, too. ST + Vintage mode is really fun, too.
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.
For Java Enterprise / Spring development (or even some of the more lightweight stuff), this editor does not match up to what Eclipse offer.
I want / need to see when dependencies in the code are not resolve at dev time, not compile time. I need to see the call hierarchy on various methods too. Sublime doesn't come close.
If you're using a more lightweight stack where you don't care about errors until you can see them in your browser then maybe this tool is for you (looking at you PHP and Javascript) but for any SERIOUS Java work Sublime is not ready.
It is a beautiful tool though. I wish there were something like this for SERIOUS Java devs.
I like Sublime Text, but I really can't use it for what I need a text editor for, which is Clojure. It is ridiculously bad at indenting/formatting Clojure and when I used it for any length of time I spent more time fixing the code it mutilated than I did actually working. I posted this bug report ages ago. If you're interested in doing Clojure in Sublime Text, upvote it! http://sublimetext.userecho.com/topic/98139-clojure-auto-ind...
A lot of comments are saying that Vim will massively increase your productivity, but I think that is completely missing what being a productive programmer is all about. Just being able to type and edit things quickly isn't even half the battle, it's less than 1% in my opinion.
Productivity in programming is measured from the time you start a project till the time you finish. So much time is often spent trying to find and fix bugs, and being productive is all about writing code in a way that minimizes the amount of bugs that show up, and being able to quickly find and fix them when they do.
Writing code at the optimal level of generality is a major factor, No amount of editor tricks can make up for choosing the wrong level of generality to write your methods. Too much generality and you are wasting time, too little and you have to deal with a bunch of special cases, or else rewrite large portions of code at some point.
It's important to be able to learn things very quickly on the spot when you have no other choice, but it's better to be able to immediately deal with situations without having to incur all of the productively losses that comes with doing that. So much time is saved by being able to get the algorithm's and the numbers right on the first try.
It's also about a psychological battle of how hard you can push yourself without burning out, which is no trivial matter.
Once you are good at all that, then basically it's nice to also be able to pick up an extra few seconds here and there with a keyboard shortcut, an editor trick, or some precision mouse mechanics.
I find it impossible to get anything bang on the first time around. I find that even the best plans and ideas can start to show problems once you get into the guts of the implementation.
Being able to input and edit things quickly greatly reduces the friction involved in doing refactorings. If I can do it fast enough, why not just refactor 3 different ways and see which one makes the most sense?
Also helps with prototyping, being able to from a conversation to a "did you mean like this?" in 30 mins is helpful.
I've been meaning to learn vim for years now. I started a month ago knowing basically how to fudge my way around with arrow keys and save with :w, and that's it. A couple of peepcode screencasts, a bit of daily 5 minute practice on shortcutfoo.com, and a month of pretty disciplined day-to-day coding later and I'm basically back to where I was on TextMate. I'm even using a tmux/vim setup for most of my Android coding, occasionally tabbing back into IntelliJ IDEA if I have to do any heavy refactoring, and even then I have a vim plugin going there.
Is it better? I dunno, hard to say. I like it. I like the tmux-vim combination and it's been a good challenge that's kept my brain engaged.
Now, I have a ton to learn, and that's awesome. But I'm at the point where I'm really comfortable making all of my changes in a vim context, without constant finger stuttering and 3 second pauses like I was doing 3 weeks ago. And it certainly didn't take me 2 years. That's nuts. Maybe 5 years ago before there were so many screencasts, tutorials and practice sites, it may have taken that long. But even then I think any disciplined coder could get up to a moderate proficiency with some daily practice, in a few weeks or months, not years.
This is an old warhorse of a debate that hardly seems worthy of HN, nevertheless here is the conventional wisdom restated: vim vs. idea vs. TM/ST is a question of taste and personal developer happiness, not proven productivity. I know great coders who swear by (EMacs/Vim/IntelliJ/Eclipse/SublimeText) to the exclusion of all others. None of it matters. Was it Knuth who said, "all editor wars lead to madness and early optimization", or something to that effect?
This seems overdone to me. Vim out of the box is a perfectly adequate text editor, and all you need to know to use it is /?xiap ESC 99dd :wq! and the arrow keys. With gq (formerly Q, RIP) you can then edit text. hlJG<>wbvn.fF;#% help too, especially for code, and c is nice, especially ci, which is a Vim innovation. ^F and ^B move around. Then, if you're programming, you probably want to build a tags file and use ^] and ^T. Vim has g] and g^], which sound like they'd be nice for OO, but honestly I never use them, because at the point where I want an IDE instead of a text editor, I switch to Emacs. I use Vim every day for non-code things, though.
Learning the above is not going to take you two years or probably even two weeks.
This is my .vimrc:
set tabstop=4 shiftwidth=4 expandtab autoindent incsearch hlsearch
syntax enable
I've been using vi (and vim) since 1996, when I had vi installed locally on my workstation but had to load Emacs from NFS over a shared 10Mbps Ethernet. A few months later my roommate Payton Whitaker (RIP) made fun of me for using elvis, so I switched to vim, and I've been using it ever since, on probably half a dozen operating systems.
I've been using Emacs since 1993, but I used Epsilon for a few years before that. I've also used Eclipse, IDEA, Visual Studio, Squeak, and XCode, among other excellent development tools. I've also written a game in locally-hosted DHTML using TextEdit (from F-Droid) on Android, which was painful. The difference is just not that big.
An IDE is not going to turn you into a hacker. Just understand the system, look for limitations, and obliterate them.
Vim out of the box is a perfectly adequate text editor, and all you need to know to use it is /?xiap ESC 99dd :wq! and the arrow keys. With gq (formerly Q, RIP) you can then edit text. hlJG<>wbvn.fF;#% help too, especially for code, and c is nice, especially ci, which is a Vim innovation. ^F and ^B move around.
As somebody who never used Vim, I seriously can't tell if you are being sarcastic here.
I was being serious, but I appreciate that my brief precis above is impenetrable to someone who hasn't used some flavor of vi.
/ search forward regexp
? search backward regexp
x delete character
i insert before the cursor
a insert after the cursor (useful at end of line)
p paste ("put") the last thing you deleted
ESC stop inserting (exit insert mode, return to command mode)
99dd delete 99 lines
:w RET save
:q RET quit
:w! RET save despite write-protection
:q! RET quit discarding changes
:wq save and, if successful, quit
arrow keys move as usual.
That much gets you an editor better than Notepad (because of instant search, with bonus regexps; multiple line ending support; and large file support), if somewhat more confusing, which you can use via ssh, and which won't lose your unsaved work if your machine crashes or runs out of battery. (Although you have to learn the :recover command to recover that unsaved work.)
Occasionally you'll hit a wrong key and end up in some weird mode, which in Vim (unlike vi) displays at the bottom of the screen. Hit ESC to escape from the weird mode unless you feel like exploring it. If it split your screen and added another window (q: does this) then use :q to escape from it instead.
One more thing I forgot at first, which is kind of essential:
u undo
^R (control-R) redo
For editing text, as opposed to code, you need to be able to refill (word-wrap) paragraphs so they aren't too ragged after you edit them. The command sequence {gq}, including the curly braces, will refill the paragraph your cursor is in.
That's 22 commands to memorize, which you can do in less than a day. That much already gives you an editor dramatically better than Notepad, and probably better than Pico or Nano, too. You can now move around very rapidly, insert and delete, cut and paste, save or discard changes, and refill paragraphs. Unix was written with editors less powerful than this.
For additional power, a second level of common commands, once you're comfortable with the 20 or so above:
h move left (without having to take your hand off the home row)
l move right
G go to the end of the file
1G go to line 1 (the beginning of the file)
w move right by a word
b move left by a word
n repeat the previous / or ? search
fe find the next "e" on the line
Fe find the previous "e" on the line
; repeat the last f or F command
% jump to the matching parenthesis, bracket, or brace
# (or shift-click) search for the last occurrence of the word you're on
^F forward a page
^B back a page
Plus a few more editing commands:
J join the next line onto this one
> indent something (>> indent this line)
< de-indent something (<< de-indent this line)
c change something (cw change word)
v highlight something with the cursor to delete, indent, change
. repeat the last edit (insertion, deletion, or change)
ci" change inside "" delimiters
ci( change inside () delimiters (etc.)
^P, ^N in insert mode autocomplete the current word
So that's another 25 or so commands, and now, after three days of vim, you can jump around in code like a madman (albeit in a single file); insert long method name identifiers with a few keystrokes; do interactive search and replace, using /, cw, n, and .; reindent blocks of code; and cut and paste in a more interactive way using v.
At this point you probably want to set a few options, which you can enter using : or put in your .vimrc without :.
:set incsearch makes / and ? search incrementally
:set hlsearch highlights search hits
:syntax enable enables syntax highlighting
:set shiftwidth=4 makes < and > indent by four spaces
:set autoindent begins each new line with an indent
:set expandtab avoids putting TABs in the file (holywar)
:set textwidth=72 auto-word-wrap at 72 columns
Except for the last one, you probably don't need to learn these; just leave them turned on all the time. They're mostly turned off by default for backward-compatibility.
There are some other commands I use on a regular basis (etyoIA*m',jkP|0^$^V^Z^GVC{}~:s) and others I use more rarely (Uq@, ZZ, :help, :set paste and :set nopaste, ^T and ^], ^W stuff, modelines, backreferences in regexp replacements) but I'm not confident that all of these are actually even valuable; I think knowing some of them just slows me down!
And of course there's lots more of vim I don't know at all (the jump list, quickfix, grep, spell-checking, cindent, cscope, abbreviations, editing files inside archives, the file explorer, folding, Arabic, Farsi, Hebrew, multiple buffers, key mapping beyond :map, and everything to do with plugins, to name a few areas).
i think a lot of people miss the whole point of emacs/vim. it sure ain't the best IDE out there, but when it comes to just pure raw editing fun-factor, it just can not be beat. i can not get the same enjoyment when i edit using anything else, there are emacs/vim plugins for sublimetext but still it doesn't have that same feel to it.
it all comes down to the vim/emacs "experience". it hooks you in and won't let you go, i'm pretty sure most vim/emacs gets some sort of high when using it.
but it's not all black and white here, there are time and place for everything. i love emacs and i can't live without it. for working on a few files at a time, i'll use emacs. but when i have a "project" to work on (10-15 files), i do use an IDE, in my case Aptana Studios (as it has the best emacs compatibility out there and has a very nice code formatter which is also top notch and you can easily customize it to how you want it to be formatted i.e; coding standards).
so at the end of the day, they both have their place. sometimes i need the laser-guided efficiency of emacs, sometimes (especially beginning of a project), i just roll-up my sleeves and get it going on an IDE.
> Ok let’s get Command-T. Oh wait that’s incredibly slow and clunky and looks jenky
Uh, what!? Command-T does much of its work in C to make it as fast as possible. I find it to be mind-numbingly fast. It is extremely well done. Did you open Vim from root or something? If it's ugly, it's because vim is ugly.
Your complaints about plugin management, Vimscript, and poor error handling are fair. When someone creates a modernized modal editor, I'll consider switching. Until then I'll suffer. It's incredibly satisfying when I do something really powerful in vim. It makes it my programming job more fun. A lot of programming is mundane editing. Editing with vim can make most painful editing tasks a fun challenge rather than a boring repetition of mouse clicks. This more than anything is why I won't switch to Sublime, even if I love its pretty face.
Vim (and unix tools) make you into, and feel like, a badass computer wizard. The more time you put into studying the spells, the more powerful spells you can cast. Newbs, do you want to be a Gandalf of computers (the answer is yes btw)? Then you need vim.
My first boss taught me it's not how much you type but what you type.
I was straight out of university and I knew my shit (as all graduates do but don't). He would spend ages looking at a piece of code, scrolling around, running the app, walking about and plonk down a few lines of code. After a year of bashing out code I realised.
Most coding happens in the planning, not in the mundane exercise of typing.
I don't think anyone doubts that - but it is hard to get faster at planning (and usually a bad idea), while it is very possible to get faster at typing/editing (the latter benefits a lot more from knowing an editor than the former). So if you want to increase your productivity, you might as well go after what you can reasonably expect to speed up.
One of the talking points I hear a lot about VIM is that you can do a lot with keyboard. All kinds of fancy shortcuts to move, delete, paste text, etc.
I've used VIM (casually), Sublime Text, and other IDEs. Currently I'm using PhpStorm and I have to say, that thing has keyboard shortcuts that do all kinds of awesome things. Jump to a function by name, jump to the next function, duplicate the current line(s), move current line up/down, select current word/line, open file by partial name, jump to function declaration.
VIM may have lots of navigation but when I want to find the declaration of a function I'm calling, I hit CMD+B in PhpStorm and I get taken either inside the file or another file where that function is defined. CTRL-J shows me a popup with the documentation for the function, CMD+P shows me the parameter list.
Personally, I think IDEs can provide a lot more shortcuts that do a lot more meaningful actions on complex code projects than VIM.
> Jump to a function by name, jump to the next function,
ctags allows you to do this.
> duplicate the current line(s), move current line up/down,
select current word/line, open file by partial name,
Any scriptable editor can do these sorts of things via a simple macro script. Now, yes the user would need to create the script, but in most case that would take less than a dozen lines of code.
And once created, the script could then run it directly, via a keyboard binding or in some case via a mouse click.
> jump to function declaration.
ctags once again.
> I hit CMD+B in PhpStorm and I get taken either inside the file or another file where that function is defined.
But if you then open a C/C++, Python, Perl, SQL or a Java file in PhpStorm suddenly those features no longer work.
Using the ctags approach the feature continues to work for any of the 33 languages supported by ctags.
I've used the ctags plugin for Sublime Text and it's pretty damn awful. Maybe it's just with PHP, but it seems to look only at symbol names and doesn't do any static analysis of the code, so if I have several functions named the same thing in various files ctags has no idea which one it should look up.
It's also not up-to-the-second. It has to re-run an analysis of the whole project to update its db. It doesn't update it's cache as you edit a file. Not sure if that's ctags in general or just the ST2 plugin.
Still, the point the author is making is that to make VIM useable you have to use a lot of plugins to get what you want while many IDEs provide it out of the box without the user needing to figure out what plugins/addons/scripts/config files to setup to get it to work.
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.
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.
Tool are designed for specific jobs;
And people choose tool to complete their job with personal preference; This is just like some soldiers are good at using sword and some prefers to ax;
There is no good or bad tool;
There is only proper tool for specific job;
And there is only tool that user has preference;
I am OK that the author do not like VIM;
It is author's choice and taste;
But the author give the user of VIM especially who want to
learn VIM a WRONG impression that VIM is NOT GOOD and is
HARD to learn and is HARD to customize which are totally
the author's own opinion; Not the true fact about VIM;
Writing this comments, just want to remind those who do not
know what VIM really is, Please try it yourself; Do not just
listen to this author's personal blah blah.
The blog's tagline seems very relevant to the origins of this post. Here comes a editor war...
In seriousness, though the author makes some good points, I cannot support his arguments that a mouse can beat a keyboard and that one shouldn't recommend vim because it is ugly.
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.
Can't agree more. I've tried learning Emacs for a very long time. I've read the emacs tutorial (which wasn't that easy to read) and now I'm having a hard time using it. I don't really know how I can get better, I always hit the wrong keys, I always forget how to do one thing...
In the end I just gave up and learned Sublime Text 2 (on the free tutorial on tutsplus). In one day I was amazingly efficient.
I'm glad I learned emacs because I can use it in a terminal. But when I'm not in a terminal, I have no idea why a modern programmer would go through heaven and hell just to learn an IDE when Sublime Text 2 let you code directly and learn along the way.
The trick is to learn to use vim commands as a language, there was a wonderful SO reply long back which described this neatly... once you master that, then the all the text in the world is yours to command
I love it when self proclaimed vim expert users talk about hjkl as some pinnacle of vim enlightenment. And what's with the 45 plugins? People who do that usually don't know how to use UNIX either. VIM is a text editor, it's not meant to replace the shell. Yes Command+T is useful, but it's not essential. And trying to shoe horn VIM into some other editor's paradigms (multiple cursors?? why, vim has better ways to achieve the same thing) is going to be frustrating.
Each and every time in posts like these I get the impression the person is CPU bound rather than I/O bound.
It's funny, but I find myself pretty much on the same situation as this guy. I've spent a couple years with Vim but I still don't "feel it".
Oh, and I touch type, and ijkl, and all that. It just took me a too much time and effort to get used to it.
A colleage asked me some time ago and I found myself telling him "just use sublime". And he's doing just fine. After two weeks, he's able to "find and replace in files" in sublime more easily than me in Vim in two years.
I'm seriously considering discarding my two years with Vim as a failed experiment and switching.
I've tried switching from Vim to Sublime Text. Can't do it. It's all frustration. Unless and until Sublime Text implements the majority of Vim-style movement and editing features, I'll be using Vim. Don't get me wrong. I think Sublime Text is great. I would even agree with the OP that it's probably the best editor for people who've never experienced Vim. Vim is like falling in love. If you've never experienced it, no big deal. But if you have...
Sometimes a specific tool that helps you with a specific task will help you be more productive. You'd probably be insane to consider doing Java programming without NetBeans or Eclipse. If you are writing code for Windows, you will get better results if you use Visual Studio.
I write a lot of Python code and I prefer Emacs for that. When I code, I prefer to keep anything that can distract me away.
Incidentally, a vim a day site, with a vim basic topic (movement/ action with example use cases) advanced topic (buffer use. Macro, .vimrc setting) and maybe a plugin review or integration tip would be bookmarked instantly, with my ad blocker off to support the site.
For the plugin reviews, I'd settle for something that let's me know what the heck a particular plugin in vundle is from the search tab.
Does it support:
-git (and other vcs) integration?
-showing which lines you altered with colored bars on the sides?
-jumping to any file in the whole directory structure of your project by just typing a partial filename?
-easily having many files open, that means, no horizontal tab layout that stops working in a friendly way as soon as the screen size is reached?
If this is an argument about the text editing software/GUI, I respect everyone's opinion, but vim keyboard shortcuts is one of the best things I learned as a programmer.
I use vim when I ssh, have vintage enabled in ST2, and my Eclipse has Vrapper for the shortcuts. Too bad these shortcut plugins don't have visual blocks though. anyways, hjkl is very addictive.
This sums up basically every problem I had with vim. It's great, but it took significantly less time to get up and running and productive with Sublime. I know people who are the exact opposite and took to vim like a duck to water.
I disagree that you have "to read at least two books" about Vim to use it well. I learned it by co-workers, the web (pre-Google no less), and mostly through the Vim help itself.
When it comes to remote typing, it's trivial to build a simple file syncing script using something like python watchdog. I use it to avoid typing remotely as much as possible.
Sometimes I wonder about all the useful stuff that could be created with the energy expelled by people arguing about which editor/language/process is better.
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.
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).
> For the first 1-2 years of your Vim usage you will be much less efficient than your current editor because of the odd yet lovable key bindings. After about 2 years you will be proficient.
Really? For me it was closer to 2 months rather than 2 years. 2 months is still a significant chunk of time to invest in learning a text editor, but given that it's one of the most used pieces of software, it's worth it.
> followed by knowing some cool tricks that you use in 1% of your daily workflow.
If that's the case, then you are not learning the right tricks. Vim has a tonne of different way of moving and editing text. Most people don't use the majority of those. Instead, they find the subset that is most useful to them and ignore the rest.
> The argument that Vim is more efficient is dubious and untestable.
It is most certainly testable. Whether or not it has been tested is another question. Is anyone aware of any serious usability studies for Vim?
> but developers are commonly on machines where the trackpad is a micro-hand movement away.
Maybe it's just me, but I find using a trackpad a lot slower than using a mouse.
> 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.
I agree that mouse is the way to go when you want to move arbitrarily around the screen. But when programming that's rarely the case. Normally, you want to move to a specific place (a particular line, the definition of the class/function, a specific place in the document). Vim allows you to do these things efficiently.
> Consider that Vim has been around since 1991. Pathogen, the first widely used, known, and celebrated path manager making plugin management possible, was released in 2008!
This is irrelevant. The important thing that, right now, Vim has a decent way of managing plugins. Though I agree -- it's embarrassing how long it took to get there.
> Vim out of the box is awful. I can’t stress how bad of an editor vanilla Vim is. Plugins are essential to make Vim usable.
This is partly true. You definitely want to customize Vim before you use it for any serious development work. But it's not like vanilla Vim is completely unusable. I ssh into servers and edit config files and write short scripts all the time. I find that vanilla Vim is more than adequate for that. Besides it's not like setting up Vim on a new system needs to be a lot of effort -- once you have your perfect setup, just stick it on GitHub. Then configuring Vim on a new system is just a 'git clone'.
> Most Vim plugins haven’t been converted to Github projects yet. Vim Scripts acts as a featureless host, which is fine, except that it doesn’t offer any benefits. It has a nasty interface, and encourages the use of the Vim Wiki for project management
No argument here...
> Ah, Vimscript. It’s bad. And yet we’re stuck with it.
Yes, I agree. But most Vim users don't really need to deal with it, as you yourself point out:
> Most experienced Vimmers I know don’t know any Vimscript
> Finding the right Vim plugins is like being in an exclusive club. It gets better around year 2 of your journey, then worse around year 3, then…
Yup, I have to agree with this one. Though there are number of resources that recommend good plugin sets; and there things like python-mode that integrate several plugins for a specific purpose.
> Everyone remaps Leader from backslash to comma.
I don't.
> Do you know what the suggested way to work well with multiple files in Vim is? It’s the arglist.
Never used it. Fuf works pretty well for me.
> Vim Is Bad By Design™ 2: GUI
I really don't get this entire section. Vim uses a fixed width font because it is a programmer's editor, and not using fixed with fonts when writing code or editing configs is madness. If you want fancy typesetting, you're using Vim for something it wasn't designed for.
RE Vim being ugly. It kind of is out of the box. But powerline (which the post mentions) + a custom theme + a custom font solve that.
RE Vim lacking GUI. Yes that's true and that is by design. If you want a rich GUI and would prefer to use the mouse to navigate between files, select menu options etc, Vim isn't for you.
> Vim is Oddly Bad at Indenting
Indentation preferences vary wildly, even within the same language; Vim provides the tools to set up the indentation you need. I agree that out-of-the-box support for some common languages could be improved.
Vim is definitely not for every one, but for those willing to invest the effort (and it really isn't as much as this post makes it out to be), it can be a very powerful, flexible, and efficient editor. I have never used SubilmeText (though heard a lot of good things about it) so can't really comment to what it would be a better/worse alternative to Vim. This post doesn't seem to address to what extent SublimeText solves the issues outlined for Vim, and it specifically should be used instead of Vim (as opposed to Emacs, PSpad, UltraEdit, etc..)
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.
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.
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.
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).
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).
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.
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).
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.
>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.
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 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.
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.
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.
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
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.
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.
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.
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.
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?).
"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)
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....
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 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.
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)