Your problem with Vim is that you don't grok vi (stackoverflow.com)
Inspired by a comment [1] made today by kaylarose. It points to a most useful list of resources [2].
[1] http://news.ycombinator.com/item?id=2910991
[2] https://github.com/carlhuda/janus
185 comments
[ 4.0 ms ] story [ 210 ms ] thread[1] http://news.ycombinator.com/item?id=2910991
[2] https://github.com/carlhuda/janus
I don't do tricks.
I switched a couple of years ago to acme (http://acme.cat-v.org) and sam (http://sam.cat-v.org). Sam is a graphical version of ed, just like vi is supposed to be but for me sam is better. It's really GUI (unlike gvim which is GUI patch on vim) and it does everything a modern ed (from Plan9) does and much more (structured regular expressions).
Both editors were designed by Rob Pike and are used today by key UNIX/C figures like Ken Thompson, Bjarne Stroustrup, Dennis Ritchie and Brian Kernighan.
All things considered, I'd still take vi(m)? over emacs anytime :-).
'More GUI' because it added the b[rowse] command [1]? That's a bit of a stretch!
[1] http://plan9.bell-labs.com/magic/man2html/1/ed
Perhaps I should have phrased it differently, if all I cared about was ed commands I could have used Plan9's ed in conjunction with a plan9 terminal, like 9term.
In UNIX I use plan9port which has a port of ed, and 9term, a terminal that acts like a Plan9 terminal.
No you can't, not in ed on Plan9.
> Even when there are newlines in the output text, 9term will not honor reads if the window is in hold mode [...] Some programs automatically turn on hold mode to simplify the editing of multi-line text; type ESC when done to allow mail to read the text.
Isn't that a bit disingenuous? From what it sounds like, you were probably able to become quickly proficient with sam and acme because you were experienced with vi and ed.
It doesn't look like those editors are without any need for documentation. http://doc.cat-v.org/plan_9/4th_edition/papers/sam/
Yes, you need documentation. How much though? I'd say very very little compared to traditional editors.
Maybe vi has a higher-than-average density of tricks due to its steep learning curve, but once you know them it's very capable.
Similar extensions exist for Chrome, but they require running a server in the background since Chrome doesn't let them execute external processes.
Vimperator and its recent fork Pentadactyl do this for Firefox, there's similar (though when I looked into it, less advanced) add-ons for Chrome/ium too, I think the one I tried was called Vimium.
I was worried using such an invasive add-on would trip me up with Firefox's new rapid release schedule, particularly as I jumped to Pentadactyl because it supported version 4 first/better) but I'm up to Firefox 6 with no problems as yet.
Maybe not. Efficiency is a measure of the time it takes accomplish something. 'Puzzling out how' can sometimes be a more relevant bottleneck than 'number of keystrokes.'
However, if, with a minute of thinking through the correct incantation, you can turn that into 10 keystrokes and no mouse movement, next time it will probably only take you 40 seconds to remember how to do it. Then, 30 seconds. Then, 20 second. Then, 10 seconds. Soon enough, if you do it often, it'll become automatic. And then you'll have locked in a more than 10x gain in productivity which would have been impossible the dumb way.
This is also the reason we spend years learning how to program instead of just copying and modifying bits by hand, by the way.
Within those full programs, there are many times when we continue to have a choice between doing it the quick but dumb way, or taking a little more time and doing it the clever and reusable way.
Of course, sometimes this can be taken too far - see yak shaving - but there are many points, while learning to program and while programming, where we face the choice between "do it manually in half an hour" and "take two hours to program something that will do it in 3 seconds". The difference between a programmer and a non-programmer is, largely, that given this type of choice, the programmer will tend to pick the latter option.
Your point is indisputable. Fortunately, it's not inconsistent with my own:
>> [Optimization is sometimes harmful.]
Optimization pays the greatest dividends to tasks which:
(1) could be brief,
(2) but are quite long and
(3) frequently necessary.
As to vim: On (1), brevity, Vim is powerfully so.
On (2), length, I don't recall any of my meta editing tasks involving "100 keystrokes and a mouse movement." Customizable shortcuts can trim down the outliers.
On (3), frequency, this surely depends on the person and task. I rarely delete every third occurrence of x between the seventh and ninth y... but if I used vim, I would make a point to.
So, I would turn to vim if there were several meta-editing tasks I routinely performed, each requiring a large number of keystrokes, each of which vim could reduce.
And hey, maybe this is the case. I'd love to see a plugin that analyzed my editing style and made suggestions to make me more efficient.
But originally I was just noting that efficiency and optimization are messy.
As a simple example of that, using a dumb text editor like notepad as the baseline, changing the same 10 characters on 10 consecutive lines will take at least 200 keystrokes (100 DELs, 100 times typing the same characters back in, plus the movement keys - about 9 to move down to the next row.
With a bit of thought, in notepad, you can reduce this a bit. use Ctrl-C and Ctrl-V to reduce the amount of typing - but you'll still need to either DEL or select the words to replace, in the same location on each line.
With a more modern text editor, you can select a rectangular area and replace the text within it. In vi, replacing those 10 strings on 10 consecutive lines will take (starting at the first character to replace, like Notepad, and assuming it's a single word inside separators):
Ctrl-V e 1 0 j c A_NEW_WORD
That's 16 keystroke instead of over 200, with no mouse movements.
This is something I do frequently enough that I didn't need to even think for a millisecond to bring to mind the keystrokes needed to do it.
Now, I'm not arguing your editing style isn't different - maybe you've never needed to do this - but I would argue that this is a fairly common programming text editing task.
Here's an example, I want to change the name of my MyClass.Execute() method to something more descriptive. In an IDE, I right click and rename and I'm done.
In vim or other plaintext editors this is practically impossible without manually inspecting each call-site. Is "foo.Execute()" a reference to MyClass.Execute() or YourOtherClass.Execute()? Without actually parsing the program it's tough to know.
I love using vim, and I'm getting better at it the more I use it, but this is one of the major productivity drains I encounter that an IDE does way better.
- braindead configuaration files. - data files that need some massaging - commenting out code blocks in languages which need a prefix comment delimiter on each line (e.g. python's # or haskell's --) - any time you are doing a series of operations calling functions in a module or from a single class/object and the name changes (e.g. foo.x();, foo.y(); foo.z(); and so on);
We changed the data format being sent over JSON now I needed to:
1) make a bunch of int declarations into float declarations, fortunately those tend to bunch up.
2) Change a bunch of getInt calls to getFloat calls, but those are also bunched up together.
Another approach is something like:
But alas, that's 21 keystrokes.(I post this now because it was closer to my first thought on how to approach the problem, and wanted to write it out to see if it was shorter. It wasn't, but maybe it'll be useful to someone. I learned about <ctrl-r>/ (fills in a search and replace with the previously searched expression), while writing it.
It's not about the most efficient command sequence at every moment in time, rather it's about building up the mastery that allows your natural instincts to subconsciously pick more efficient paths.
But, reading this reminds me of how much I like GUIs. Yup these movements are great. I get the appeal of turning selecting text into a dumb programming trick, I'm sure it makes you feel very clever and productive. Of course I can do all this stuff and more without even consciously thinking about it using a mouse.
Go do multi file grep in BBedit in front of an emacs jock one day. Look what I can do by finding a menu item!
Douglas Adams used to talk about how powerful formatting features in word processors were a great way to procrastinate.
One of the reasons vi/vim is so much faster for me is that there isn't a need to move between the mouse and keyboard with the requisite hand/eye/mouse/re-home coordination. Yes the key combos are bizarre, but so is the querty keyboard layout for that matter. Once you learn it, your fingers act as a direct connection between your brain and the editor. A mouse can't do that.
Ooh, I think we found part of your problem.
Is there something it does that's better than M-x grep? I'm asking honestly, not to be snarky.
And either way, it's not that menu items are bad... it's just, well, I've been using Emacs for ~20 years now. Across god knows how many different platforms, installations, and technology tool chains. How many times have you re-found that menu item? And how does their menu item differ from the one in (TextMate|VisualStudio|XCode|Eclipse|...).
If BBedit is the only editor you've ever used or will use, great. But honestly, I don't want to find move next paragraph, spell check region, or reindent block ever again. They may be in the editor, in some menu somewhere. It may even be similar to the place I found it last time...
Isn't this just using ack? (:Ack in vim, not sure of the equivalent in emacs)
:nmap <C-f> :!ack <cword><CR>
Using ack and the emacs mode http://nschum.de/src/emacs/full-ack/ I search a hundreds of megs in source in ~5 seconds. I have yet to think of something that there is not already an emacs mode for.
You mean something like this: http://i.imgur.com/0pieh.png ?
It has been almost 10 years now since GNU Emacs got GUI, and XEmacs (as the name suggests) had it even earlier, and yet many people still believe that Emacs has only console interface. I think the main reason is that most Emacs users (me included) turn off menu and tool bars so that they're not distracted by them -- almost nobody uses them anyway, because moving hand from keyboard to mouse and clicking through menus is so annoyingly slow.
There are many uninformed opinions in this thread, about Vim, Emacs and heavyweight IDEs like MSVS or Eclipse as well. Please, refrain from bashing things you do not know, because it usually sounds silly for those who do know them. But, yeah, all's fair in love and war, especially when you're fighting for your loved editor.
I have reams of arcane bits of information to commit to memory already. .Net in two languages plus VB6 for legacy code. SQL in more dialects than I care to list, each with their own quirks and limitations. HTML and JavaScript. XML and various associated technologies like XPath. That's just professionally; once I go home I can add in photography and music straight off with others at different levels.
There's only so many things one can usefully commit to memory (edit - yes, I meant am prepared to dedicate the time to committing to memory); odd bits are just easier to look up. So why, exactly, should I voluntarily use a text editor whose interface was already far behind the state of the art when I started school?
:q!. I've had others try to persuade me of the joys and power of vi; I'm not even slightly convinced and that is the one command I'm committing to memory.
That being said, one still needs to learn it to begin with. I'm lucky that I decided to sit down during college and at least learn the basics. I'm not convinced that it makes sense for every one to learn VIM or Emacs if they are perfectly proficient as they are now. For me, it's the right answer as long as I'm not pairing with some one who doesn't know VIM.
I tend to be lazy and use keyboard shortcuts as much as possible regardless of the OS I'm using. With vi it's basically heaven since they were able to make it a powerful text editor without a modern GUI.
Can you refer to any scientific research to back up that statement? My impression is that the more you use your memory, the easier it is to remember new stuff. Memory seems to be more like a muscle, the more you use it the stronger it gets, rather than a bucket that can get filled up.
And after a while -- and it is not all that long of a while -- it becomes second nature. The fundamentals become a part of your fingers, just like touch typing. You no longer have to hunt and peck to type out the word "lightning". You just do it. vim's keybindings become similarly engrained. It just takes practice.
And what exactly is this state of the art you talk about? If it's the IDEs you are talking about, saying that they suck at text editing will be an understatement. Code completion, refactoring support etc isn't text editing.
When I am using a language which requires a lot of boilerplate and demands an IDE, I go for some plugin which gives me vim keybindings(eclim for java, don't do much C#).
Code is text at the end of the day, and something which isn't good at munging text isn't going to be my code editor. Eclipse, Visual Studio are both good tools, but they aren't good at munging text, not at all. And the boilerplate code they generate doesn't do anything to mitigate this.
> So why, exactly, should I voluntarily use a text editor
Because it isn't a pain in the ass like the IDEs when it comes to text editing.
Oh, that's easy: Emacs :-)
Before someone tells me it does, I've had competent vim users try to get C++ support set up for me before, and it is almost worse than useless in code completion, code refactoring, and even trivial things like "jump to compiler error/warning".
For example, in my gvim, control-p shows the autocomplete list.
If you think it does, I'd be interested to know your setup, as I've never been able to get such a thing to work effectively in vim.
(disclaimer: I don't use it, I turn off completion everywhere I go.)
http://www.vim.org/scripts/script.php?script_id=3302
In Vim, these features tend to be plugins. Vim ships with some of these plugins by default (e.g. C and C++). Autocompletion with C and C++ works using cscope and ctags, which also are very powerful code navigation tools. There are plenty of other tools available.
Vim has excellent "jump to compiler error/warning" support called the quickfix list. Just invoke your compiler using :make (you can configure what it does, by default it runs make) and look at the errors in :copen, browse with :cnext/prev.
All your arguments against Vim were false. Please don't spread such BS that can scare new people away from Vim.
Vim's "jump to compiler error" tends to get confused by C++, and gets very confused by clang (this is from experience). There are indeed a huge number of tools available, for code navigation, for C and C++ in vim. Each of them has it's own faults and none of them have anywhere near the functionality of eclipse (although last time I tried vim, clang_complete didn't exist, and might now outperform tools from last time I tried).
For your :q! example, it looks daunting but you really don't end up memorizing it verbatim like that, much like you don't memorize adding semicolons verbatim to the end of your C# lines of code or adding closing tags to markup languages, it's just part of the language, a line end implicitly requires a semicolon so you just do it, vim commands are prefixed with colons so you just do that too.
The q is quit, which is hardly any worse than remembering Cmd-q or Ctrl-q is quitting for OS level shortcuts and the exclamation mark means "force", so it's usually unnecessary unless you're trying to quit without saving your changes, or doing something the command otherwise wouldn't normally allow. The exclamation mark is used in tandem with other commands too, so you don't mentally remember ":q! is how I quit a file without saving changes", you memorize how to build up the command you want, "I want to issue a command, type a colon" then "I want to quit the editor, type a q", then "I want to quit without saving, so force it, type an exclamation mark". And if it really bothers you, you can configure vim to prompt you for an action if it would normally require a ! and you left it off.
Viper? Vim mode?
That's another story that these vim modes in emacs are hated by both emacs and vim users. I don't know who exactly they cater to.
Viper with Vimpulse get me close enough and still allow me to modify my editor in a lisp dialect. I'm willing to sacrifice some of the edge case uses of Vim to have this power.
It's not ideal but it's currently better than vanilla Vim or Emacs. I have hopes for Yi in the future but it's not there yet and development has only recently started to pick up on the project again so it has a ways to go.
That's similar to not learning English because the dictionary is too large to memorize.
As jvanenk says elsewhere in here, it's muscle memory, not memorization. You don't "remember" how to walk or use a pencil, you just think about the goal (move body over there, write sonnet) and muscle memory takes care of the details.
Most vimmers have had the experience of someone watching over their shoulder and they say "wait, how did you do that." And then you have to pause and think it through, because you yourself don't know anymore, it's just in you.
It would be ludicrous to try to learn all of vim, and it's absolutely unnecessary for using vim (or any other fine grained editor) effectively. You learn what's useful to you at the moment. If you do anything a lot that irritates you, there's almost certainly something in vim (or any other power editor) that will reduce it down to a keystroke or three.
I'm not saying you should learn and use vim, only that your objection (too much to learn) is misplaced.
I had the interesting experience of learning vim over the course of many shared ssh+screen sessions with an experienced vim user, trying to get work done. "How'd you just do that" represents my primary method of learning for a while, and I definitely got a response of "hang on, let me try it again so I can tell you" more than once.
I agree wholeheartedly. Watching my colleague to code in vim is a turning event of my programming career.
You meet these things for the first time and think, why would I bother learning all that arcane knowledge just to do this one thing, but then later you realise that you can leverage that knowledge across a wide range of tools. Obviously you mention C# and .Net so you swim in a different pond and are less likely to see the same level of reuse, but that doesn't mean it's not there.
I'm an emacs guy not a vim guy but this fundamental point is similar. Being good at vi means you're good at editing arbitrary text whether it's VB6, SQL, HTML, JavaScript, XML, wiki markup, the output of 'find' or 'ls -l', or some randomly formatted table that someone sent you in an email.
I learned how to drive a manual car a couple years ago and these days I just don't think about it anymore. I shift completely absentmindedly, it just happens. The response is built into my body, I no longer have to provide it any thought power.
I've become much more productive with vim than I have with any other text editor.
If you invest the knowledge to learn Vim now, it will still be useful as long as keyboards exist and are used to write programs. You can also use it whether you are on Mac, Windows, Linux or whatever future OS comes out. You can use it over a high latency flaky SSH connection surprisingly effectively.
The notion of state-of-the-art is a red herring. Vim is a reasonably optimal mapping of all the keys on the keyboard to general purpose editing tasks with reasonably optimal internal grammar for combining commands in a logical way. In terms of general purpose editing, I don't think it's possible to make something "more advanced" than Vim, just different.
Of course in the GUI and IDE department there are many advancements, but how much are these worth? The answer is that if you pour millions of dollars into IDEs for constrained languages like Java you are going to get some specialized tools that outperform general tools like Vim or Emacs without similar language-specific optimization. That's great as long as you stay within the approved ecosystem, but not so good if you want to venture off into a new language or DSL that doesn't have IDE support. Personally that feels stunting to me; I want to try out new technologies at will without feeling unproductive until some monolithic software package decides to catch up.
Over the years through all the GUI advancements, the UNIX philosophy has proven that it still provides some of, if not the most fertile ground for creative hacking. I'd rather have 200 CLI utilities than 10,000 special purpose apps with thousands of non-orthogonal knobs and dials. Vim is a similar foundation for text editing. I can get some amazingly powerful plugins for specific uses (Fugitive makes "state of the art" git GUIs like Tower look like Playskool toys), but its bare functionality for manipulating text files is enough to get my comfortable and productive in any new language quickly, and I know I'll never have to learn a new editor for the rest of my life.
I use auto-completion when I think it's worthwhile, my vim supports tab completion in python files. My current exception is using Adobe's Flash Builder for Flex development since I needed to make programs now when I started, and didn't have time to learn the language+standard libs (which has consequently meant that I still don't know those things as well as if I had avoided auto-completion). Fortunately Flash Builder is built on top of Eclipse, so the occasional time I need Eclipse's integrated debugger for million line Java projects it's not a foreign interface. Yet I've never bothered to truly get used to Visual Studio, or Dreamweaver, or Delphi. To me those seem like the extraneous pieces of information I don't need since they're useless outside their very specific domains whereas vim is an investment that pays off time and time again in all sorts of areas.
http://www.viemu.com/
I selected emacs in large part because I was tired of learning different editors, one for each platform.
Now, does vi(m) have a similar feature or did you mean (as I expect you did) that editing over a terminal connection to a vi instance that runs on the actual server was surprisingly effective? Because if you did mean that, you haven't seen actual bad connections yet ;-)
Don't get me wrong, I always have a Terminal window open, I love the command line. But I wouldn't use it for remote text editing unless it was an emergency. Also, I kinda like syntax highlighting in my editor.
Whether or not this extends to color depends on the terminal / termcap support at the remote end, but at the very least bolding and reverse-video should be supported.
In most instances, you'll have full color syntax highlighting, though I've found I've got to down-rate my terminal. e.g.: rxvt-unicode isn't known on all systems, but rxvt, ansi, linux, or xterm generally are, and dropping past "rxvt" on that list is very, very rare.
Sometimes, though, remote editing is where it's at for whatever reason, and vi/vim is still probably the least sucky tool for such an instance.
Even if it means doing copy/paste into the remote session:
:r ! cat <paste> EOF
... works surprisingly well too.
I edit files across a satellite connection on oceanographic vessels a few thousand miles away at sea (often 1000ms+ pings) and sshfs is wonderful
and as the other poster points out, syntax highlighting working fully requires correct terminal settings
And yes, as you already observed, I stand corrected on the point of syntax highlighting.
However The Fallacies of Distributed Computing [1] are not just whimsy.
[1] http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...
http://vim.wikia.com/wiki/Editing_remote_files_via_scp_in_vi...
It's not perfect, but I prefer it to using vim inside a remote shell and waiting for cursor to move to the right point after I press a few j's.
Command mode in vi is kind've like a Caps Lock, but for commands. "lock" goes on (enter command mode) and you're running commands. "lock" goes off (enter edit mode) and you're entering text.
I realise it's not quite the right way to look at it, but it helped put a big piece of the puzzle in place.
Besides, the basic cursor movement keys are standard across all text-editing widgets, at least on a Mac, and those are the most crucial to have in common. Using a "dumb" editor like Vim or Emacs seems like a premature optimization to me.
I can use modern WYSIWYG text editor on any unfamiliar platform anyway, my aptitude with computer GUIs is sufficient enough for that. Notepad++, Textwrangler, MS Word, whatever... they're not exactly difficult to pick up.
Vim is "far behind he state of the art" same way Lisp is. That is it's so far beyond state of the art that it takes most editors/people years to realize what they have is just a weak / limited implementation of vim.
Given that, I STRONGLY believe people's brains work different. And what may be the most awesome editor for us is not the same for you.
Given that, you can not know if vim is for you without using it (daily for programming editing) for at least a year.
I first learned vi in 1986.
It sucked for about 2 weeks.
Then I got it.
For the subsequent quarter century, I've used iterations of the same tool, as my principle editor since the mid-1990s.
Since then I've used: WP4x+, WordStar, DOS EDIT, EDLIN, TSO/ISPF editor, MacWrite, MS Word in multiple incarnations, AmiPro, EVE and EDT on Vaxen, and a slew of other proprietary editors (as well as Emacs, pico/nano, ae, Lyx, AbiWord, etc.).
vi/vim is a standard you'll find on any 'Nix box, from BSD to SysV4 to Linux to Mac. Ports exist on a great number of other platforms.
As with other 'Nix tools, a key advantage of being a free software program is that it tends not to up and get replaced. The fundamental philosophy of vi (a full-screen curses editor based on ed with its commandset) continues through the modern incarnation (though I've got to admit that going back to old-school, un-featured 'vi' instances sucks).
While the free versions are now generally available, I ended up learning and unlearning a lot of emacs when I switched to a shop that 1) didn't have it and 2) the boss wouldn't allow it to be installed (didn't know enough at the time to realize that was a prime hint to up and leave).
I've saved myself having to unlearn a great deal of stuff by sticking with vi/vim.
Now: if you've got an editor which works for you _and_ can offer the same promise of persistance, bully for you.
But at least now you understand the appeal.
I think I spent the first few years getting to the end of a line with shift-A and Esc, copying lines by trying 13dd u 14dd u 15dd P jjjjjj p, etc. (Side note: even as I was editing this text I kept hitting ESC and bbbbbb.) I'll likely never know all the things Vim can do, but it's already enough that it's my fallback editor when I need to do a lot of editing or text manipulation.
Also, don't use :q!, just use ZZ, its quicker.
If you want to learn how to do something vimgolf is a good choice as the goal is to do a task in as few commands as possible.
Think of it as talking to your editor in as minimal a way as possible. http://vimgolf.com/
But ZZ is equivalent to :wq, which is different. If OP finds themself in a text file in vim by accident and started typing a word, they will likely NOT want to save those changes. (Hence OP's :q!, rather than :q.)
That is what view/more/less are for.
There, you're all caught up.
Cut, Copy, Paste, Find, Find Next, Replace, Load, Save, Print, New Document, Undo, Redo.
All of those things are standard in all mac apps, except vim of course.
It occurs to me (just now, so this might be a poorly thought out point), that vim (and emacs) can be viewed as the 'anti-unix'. Unix is designed around tools that fit together in a coherent manner. vim and emacs are huge worlds, uniquely designed to be nothing like anything else.
And expecting Vi(m) to use whatever shortcuts are standard for Mac applications is of course absurd. It isn't a Mac application, it's Vi.
But, I have to use lots of programs every day, and my "muscle memory" allows me to get a lot of consistent functionality out of all the programs I use. Whenever I've taken up vim, I've started having trouble with Eclipse/Chrome/TeXShop/etc...
Many people's solutions to this problem seems to be:
1) Use vim for everything or; 2) Make everything use vim shortcuts.
Neither of these appeal to me.
As for design, Vi is a perfect example of Unix design. It's a text editor. It does one thing and it does it well: edit text. Some may disagree but I also think that Emacs is a good example of Unix design. It does one thing (interpret elisp) and it does it well. By the way, at it's core Emacs is an emacs lisp interpreter, not a text editor (despite misconceptions).
While this is very true, it should also be mentioned that Elisp is a lisp designed for writing text editing tools.
(Die-hard lispers will cry blasphemy here; I realize that you could get the same effect in $lisp with a proper set of macros. I maintain that the distinction is not relevant as lisp blurs language and library).
And variants of course
* Cut - d
* Copy - y
* Paste - p
* Find - /
* Find next - n
* Replace - s///
* Load - e
* Save - w
* New Document - e
* Undo - u
* Redo - Ctrl + r
I'd call those pretty standard.
FWIW, ed uses a lot of those.
Cut, copy and paste work a bit differently in Vim. There's a whole lot of clipboards (called "registers") in Vim, some of which have a special purpose. This is a very powerful feature but it doesn't work like the rest of your apps do so it may be misleading at first.
Find and replace is another feature that's not so easy to get started with in Vim, but, again, it can do regex matches and a whole lot more than your regular text editor can.
Vim has also got a neat undo feature, which actually stores a tree-like history.
New document, save, print and others can easily be found in just about any Vim GUI.
If you want a smooth start with Vim without having to learn everything again, you can use evim (bundled with default Vim) that uses all these Windows-ey "default" keybindings.
It's also worth mentioning that most of Vim's keybindings are default keybindings in Unix since the dawn of man (before Ctrl-S was ever used for saving anything). E.g. j and k for scrolling up and down, / and ? for searching, etc. For example they work with the "less" pager in Unix.
"You guys just don't understand why I eat dirt. I'm on a higher plane of existence and you just don't get it."
This works fine in vim. It's not suggested practice since moving your hand over to the arrow keys is slow, but it works like any other editor.
Without that, Vim is reduced to a quick hacks editor, or an editor for languages where no realtime parse is possible.
There are similar plugins for other languages.
Now, I much more highly value consistency. In any given day, I may edit one of a dozen languages or hundreds of config file formats.
It also depends upon the language you are using. I don't know if you're using Java or not but one can use all the help possible in catching typos while working in Java just due to the verbosity of the language. Programming in Java without an IDE is like working on rails apps without using any of the scripts and generators, it's doable you just have to write all the boring boilerplate code manually.
Also, using autocomplete to explore APIs is one of the worst programming practices I can think of. The docstring for one method is not nearly enough information to tell you why you should call the particular method of the particular class that autocomplete suggested. In order to be sure you've made a good API use decision, you need to read the documentation and code for the library, and then decide to use it. Anything else is a hackish shortcut that will surely waste more of your time than it saved.
And, if you can't remember the names of methods you know you want to use, maybe it's time to refactor. Or practice remembering. If you want to be bad at programming, Eclipse will make your life slightly easier. If you want to be good at programming, start programming and stop commanding an autocomplete tool.
I primarily use Vim as my IDE, so I'm not saying I prefer Eclipse or other IDEs. But I don't pretend that Vim is perfect and using an IDE is a sign of inability.
And if you need code completion, your names are too long ;)
As for variable naming, the better question is:
Why would you willingly choose less descriptive variable names when there are editors that will help you produce more readable code?
Typing is easy. Programming is hard. Optimize for programming.
Interestingly if you want to do any Japanese text editing, most IDE's or editors fail horribly. I almost always find myself falling back to Vim.
Mind you, I really like textmate. Sadly, it sucks at Japanese. And will for the time being.
I do a lot of Japanese text editing and I've also been learning Vim recently, but I had no idea that Vim recognizes Japanese words. Many times I've thought, "It's too bad I can't (effectively) use Vim for Japanese also," but I was just assuming it wouldn't be able to parse the words without spaces.
I just tried it and my mind was blown when w moved forward in completely logical increments without plugins or anything. I still can't believe something like Vim would include a native Japanese parser, but now I think it's time to rethink my workflow...
EDIT: I just tested some more and realized there isn't actually a semantic parser, but it's just treating any grouping of one syllabary (kanji, hiragana, katakana) as a word. Except for some debatable weirdness around conjugated verbs, it actually feels fairly natural given the rhythm of the different characters used in Japanese.
Most programs are about getting results now. There usability is most important. But some programs (like vi) are about getting extremely, awesomely better results later on. These tools need the student/user to be in the valley of pain for a long time that they can actually reach this point of enlightment. I would argue that such kind of program also needs to get rid of users, who don't have the motivation or persistence to stay until a certain point of enlightment. Giving up on vi is good for the people who do. They probably wouldn't need this kind of power anyway. And those who desperately want and/or need it will eventually come to that point of understanding the other modes and commands of vi in the end.
This might be reasonable for the sort of user who only starts up Vim on rare occasions, say when editing a remote file via SSH, and doesn't care to grok the modal style. It would certainly reduce (though not eliminate) confusion for people who encounter Vim for the first time with no prior knowledge, see a strange screen with tildes running down the left side, and spend 20 minutes trying to figure out how to quit, only to give up and just kill the process manually. But crucially, it defeats the _entire purpose_ of using Vim for the non-casual user. `i` is the command that turns Vim into little more than MS Notepad with syntax highlighting; it strips away 95% of Vim's power. If you make insert mode your default, then there's really no reason to be using Vim at all.
Vim is the type of application that expends very little effort coddling new users and instead focuses on being as flexible and powerful as possible for the veteran. That means its reputation for being difficult to learn is not entirely undeserved, but the majority of users who do surmount the learning curve grow to appreciate Vim for its peculiar style, in spite of the initial difficulty it brings.
The other problem with the 'insertmode' option, of course, is that the sort of user who would want to do such a thing is the least likely sort to know that such an option exists or how to activate it.
In a couple of weeks, that will become muscle memory. Then I pick something new.
I know probably less than 0.1% of Vim, and I still find it better than any other editor I've used. One day I hope to reach 1%.
Vim, on the other hand, is more of a tactical editor; it lets you compose a small set of primitives into a incantation that will rearrange arguments in a function call, and then compose that with the repetition primitives to do basic refactoring. The effect is the same, but the way you go about it is very different.
Say I have a line as follows:
In other editors: Symmetrical and consistent, to my mind.In Vim:
The last case there is exceptional. It's a small thing, but not being able to put the cursor on a real or virtual 'end-of-line' character in Vim makes me feel constricted.I think that the between chars cursor model is simpler because you then have two choices: act on the preceding chars (thus, delete with C-h or <Backspace>) or act on the succeeding chars (thus, delete with C-d or <Delete>). By contrast Vim is more complicated because from the current character you have three choices: act on the preceding chars (thus, delete with X), act on the current char (thus, delete with x), and the principle of 'completeness' suggests a third: act on the succeeding chars - which AFAIK is not available in Vim and so it feels lop-sided to me.
Ironically I think that it's my 'programmer head' which makes the between chars model appeal to me more, as I think of the file as a bunch of bytes (well, maybe multibyte characters) and the text editor as a glorified hex editor, and I just want to choose a position and insert or delete chars regardless of whether they're alphanumeric, LFs, or whatever. Whereas Vim's model of manipulating words, lines and sentences suggests to me a fit with people writing in human languages. Why, non-geeks should love Vim, perhaps except for all the key commands to learn; one imagines an alternate universe where the common keyboard evolved with two Return keys instead of one, labelled "Open new line above" and "Open new line below", and other Vim-inspired niceties - and I wonder whether your archetypal 'grandmother' might find it easier to write letters on the computer in that world than her current futzing about in Microsoft Word.
I see your point though, it is different. It does take a little getting used to, but if you slowly teach yourself the motions you'll learn it unconsciously.
As for your example, you're running into this problem because you are manually placing your cursor. If you watch someone who uses vim, they almost never use the keys hjkl, or even x. When you type w to get to the next word, or when you search for something, the cursor will be conveniently placed for whatever kind of deletion you plan on doing. x is for deleting one character, if you ever want to delete more, you move to where you want to start, then use a motion and delete. For more precise control enter visual mode and delete. But never hit x three times in a row and stop to think about whether the cursor is going to shift left or right after the first x.
Vim does have a concept of words, sentences, and paragraphs, but that's because it's not a programming editor, it's a text editor. It also has a concept of lines, braces, parens, and angle brackets. That's because programming is a common text editing exercise :)
1) Hitting escape pops you out and left. So insert - escape - insert - escape, etc, gradually moves the cursor left. This feels weird to me. Everyone calls it "insert mode", but perhaps it would be better called "append" mode, because append is the exact opposite of command mode, in the sense that a - ESC - a - ESC, etc, leaves you in place.
2) It makes it annoying to delete the last n words I typed. I want to go, "oh, mistake! ESC db..." but that leaves the last letter hanging around. I recently realized you can do "ESC daw...", at least.
Anyway, there is this in the default vimrc:
So you can use jj (or any other mapping) instead of Esc and get the behaviour you want.I think the recent DevOps movement (which is actually a label to something that's been around for a while), is strongly correlated with vim (or emacs) users as well. Developers who get their hands dirty on remote systems often want a tool as ubiquitous as vim.