I've argued for years that vim is one of the few good examples of modal design since it allows for quick entry of the command grammar without modifiers and the command grammar is an excellent fit for the domain. Whenever I bring this up with an interaction designer, I'm told there is no such thing as a good mode. The citation chain has always wound up at this paper and while I generally agree with the paper's conclusion, I'm frustrated that the editor is used in the most inspid way possible to generate mode errors (at the rate of 3-6 in 10 minutes of editing...). The problem given in the paper is solved by `:%s/\<[A-Z]\+\>\zs/errorerror/g` and I could probably do it a half dozen other ways.
Every time I read the paper I tell myself I should make/acquire a pedal and try it out but I've always been too lazy.
"other experimental variations were later built and tested, including foot-pedal operated, knee-operated, even head-operated ("nose pointing") devices."
VIM clutch does not seem to prevent mode errors, though. For that pedals need to have feedback. I.e., if one hits 'a' out of habit or accidentally, stepping consequently on the insert pedal would predictably enter 'i' character. That would be avoided if the pedal changed to pressed state depending on mode.
That said, for me as a pianist the idea of mode pedal looks pretty awesome. It just needs to be developed a bit further.
Just need to make sure pedal down is idempotent. Having the pedal send something like Shift+F2 and then `nmap <s-F2> i` `imap <s-F2> <Nop>` takes care of that. Escape is always idempotent so no issues there.
The escape bit would work great, but there are so many other ways to enter insert mode apart from i that I'm not sure how useful it would wind up being.
That's what I was thinking as well. I really don't enter insert mode using i very often at all. Fun project, but I don't think it would actually be productive to use.
Glad to see other people experimenting with this kind of setup. I've known a few people to use one of these [1] for Emacs (for Ctrl & Meta), and I finally picked one up a while back.
My setup has one pedal bound to Escape for Vim, and the other two switchable using F keys and some xbindkeys magic. By default, they're "switch WM workspace" (sort of like Alt-Tab) and "switch window focus within a workspace" in Awesome WM, but I can change them to e.g. j and k for reading my email, or have them run various scripts, or whatever.
It's a lot of fun to use, but I haven't been on it much lately having switched to a standing desk and I haven't yet figured out a way to make the two play together nicely. And, as always, I've been meaning to throw the scripts & dotfiles on GitHub, but I'm a slacker.
If OP puts it on Kickstarter (no pun intended), I'll be your first pledge. Would really want pedal-up event too and customisable for other apps (ie you can switch the key mapping).
If pedal-up worked, it would be neat to be inserting only while the pedal is depressed.
Not enough. "I don't use always use vim, but when I do" I enter insert mode in all kinds of ways that are mostly never just i. Usually c and a movement. I'd rather just have one switch that did esc when I hit it.
In 1992 research was done that proved that modes can be made less confusing with feedback. Visual feedback is more easily ignored than audio feedback, but the best is kinesthetic, or physical feedback. Jef Raskin championed the use of "quasimodes", which are modes that are consciously maintained by the user. https://en.wikipedia.org/wiki/Mode_%28computer_interface%29#...
I don't know how this would work out ergonomically. My dad is a cab driver and he often complains that pressing the clutch with his foot often giving him RSI kind of pain.
But however I think this is purely subjective. From an experiment perspective, this is really cool! And this generally qualifies into what could one call a 'real hack'. This has a air of freshness to it.
Now the real power of vim is in getting into a mode called 'extreme keyboarding'. I didn't realize this until I read Tom Christiansen's seminal essay "Zenclavier: Extreme Keyboarding"- http://oreilly.com/news/zenclavier_1299.html
This is to ultimately turn the keyboard into a Musical instrument, and then to become 'one with the keyboard'. Totally loosing any realization that you are actually typing. Read the essay carefully and try to understand how he tries to talk about 'moving in and out of zones'.
I started learning vim a few days back, after I suffered from Emacs Pinky. When I started question I asked was, 'Why should I memorize so many commands'. The thing is I quickly realized that being proficient with vim, requires you to understand some things. You really have to understand the vim paradigm, without that straightly diving into vim wont be much productive.
You have to learn h,j,k,l are not just navigational keys but also can be combined with multipliers like 20h(Moves 20 positions to the left). You basically speak a 'Editor programming language'. You program editor with a stream of characters. Like for example you my say 'copy this line, move up 20 positions and paste it'. This will be yy(copy current line) 20k(Move up 20 positions) p(paste it there).
So you have to basically learn these things in detail. You can use position stuff for things as well. Like for example 'd' specifies 'cut from here' and 'y' specifies 'yank/copy from here', but to where? the next character specifies that for example '$' specifies the end of a line. You can also do something like 'y2/foo' this means 'yank from here till foo'. You will have to learn regular expressions, touch typing, and many other text processing stuff. Basically you learn a terse programming language which is written as a stream of characters with data on the editor as a input.
Recently a colleague of mine introduced me to a editor command called ': perldo' you can do perl oneliner on the editor line by line.
The only thing is I couldn't find a book so far in my early days of vim, which completely teaches the 'zen of vim' completely in the paradigm, in which one needs to understand it. So vim is really about these things, I don't how far the pedal/clutch experiments gel with this concept. You may need a totally different editor paradigm to work with this setup.
In the meanwhile, if someone knows of a book that talks of vim in the way its supposed to be explained please recommend. All I could find on the net was cheat sheets, books that teach a commands in bulk.
I also never used that feature and I've been a heavy vim user for maybe 8 years.
Thanks to the relative line numbers patch being merged in finally (:set rnu and now you show line numbers relative to your cursor) you get easy moving up and down.
I prefer the easymotion plugin (https://github.com/Lokaltog/vim-easymotion/) that annotates your file with little markers (like the vimperator/pentadactyl/vimium browser plugins use to click links with the keyboard) that allow you to jump around extraordinarily quickly.
It was, and still is, a learning curve since it adds to so many basic vim commands that are muscle memory for me by now but it's worth it.
Note: this post assumes Vim, not other implementations of VI
If you type fast, you don't want to have to spend time correcting for line estimations that are slightly off as a result of thinks like 20h. For navigation, just use forward slash to search and you'll land right where you want. It's also almost always faster to use f/F/t/T in conjunction with semicolon or comma for jumping to specific letters than using h or l. The # and * keys are also useful for jumping to words in a specific line. Failing all of /?fFtT#*, it's still going to be faster to use ^0$wWbBeE than hl unless you're one or two characters away from where you want to be. But you shouldn't even need to navigate much within lines, since text objects let you edit entire units of text, regardless of where the cursor is within those units. People who come from an emacs background (and use the default editing environment instead of evil) can't even imagine how powerful Vim is as a raw editor until they try it. I can only edit in emacs for long periods of time if I'm using evil to emulate vim's text objects.
In emacs, we do the same with C-s (search-forward) and C-r (search-backward). It is highly recommended to "jump" to the exact text you want, rather than fiddling around guessing and correcting numerical character and line jumps. Just a bit of support from the dark side!
That's interesting. When I used Emacs with the default bindings, I only used C-s or C-r when I was genuinely trying to search for something, not for navigation. I think I normally used an estimation like C-u 2 0 C-n exactly where I would recommend against doing 20j in Vim. [I meant 20j instead of 20h in this post's grandparent.] This discrepancy probably arose in part because I tend to edit documents as I go in Emacs since there's no mode switching, meaning I didn't usually have to do much jumping around in files, and in part because in Vim I'm used to using the /?nN keys as the motion components of editing commands, not just as isolated motions for navigation, so my fingers are used to jumping to places by searching.
Usually, yes. The two places I find myself using a count on h or l are 1) in nonce key bindings, and 2) when there's a lot of instances of what I want to jump to near the start of a long word, followed by a gap without the character, followed by where I want to jump. If I'm faced with www.wikipedia.com/something/wouldyouchangethis it's simple to say 10lfwcw - if I'm off by 5 in either direction it doesn't matter and ballparking like that is easy.
Yep, I'm the same. I do however jump 5 or perhaps 10 lines or words in the general direction I want to move in and correct from there. Other times it's less keystrokes to just hit / and search for the next location.
For what it's worth, I remapped vim's navigation keys from the awkward hjkl to the normal inverted-T arrangement i,j,k,l. Then I remapped the inserts, i & I, to h & H.
With that, my natural finger movement on the arrowkeys and on the vim home row match each other.
The reason vim's navigation keys (hjkl) today are arranged the way they are, left-means-down and right-means-up instead of up-means-up and down-means-down, is among the dumbest reasons there can be. Decades ago, the keyboard Bill Joy happened to be using when he wrote vi just happened to have arrows printed on the keycaps of the hjkl keys. He was trying to think of ways to make memorizing lots of commands easier, so he decided to take advantage of what was printed on those keycaps. There were no arrowkeys on that keyboard. That, in itself, was not a dumb choice, because it would have been a useful mnemonic on his own keyboard and he'd probably never seen an inverted-T set of arrowkeys, which didn't become popular until years later.
The dumb part is the insistence on maintaining this onion in the varnish as sacrosanct decades after that silly keyboard disappeared and in an era where every new vim user is accustomed to using the inverted-T arrowkeys found on virtually every keyboard. Anyone who, for some reason, hasn't ever used his arrowkeys picks it up immediately: up-down-left-right mean up-down-left-right. Got it.
That's why so many people who want to use vim have to be "broken" of the habit of using the arrowkeys and forced to learn an additional, weird arrowkey arrangement, because ("trust us") using the home keys is better.
Well, using the home keys is better, but not because of the awkward arrangement. That part is worse. It's better because that's where your fingers rest normally on the keyboard, from where you can operate the full set of vi commands and enjoy its full power.
You can have both. It wouldn't take much convincing to wean people off the arrowkeys if both sets of "arrow keys" on their keyboard had the same natural arrangement they've been used to for years.
I was worried when I abandoned the onion that it would handicap me on plain-vanilla installations of vi/vim until I realized that, these days, yes, there are two sets of arrowkeys on every keyboard, and I can use the real arrowkeys if I have to work on a version of vi/vim without my .vimrc, because they're arranged just like my ijkl. I can live with using the real arrowkeys for a while, and if I'm staying longer, I'll "curl -O mydomain.com/myvimrc" and restart vim with my full customizations and go back to the home row. (I also have my zsh in vi mode, and my .zshrc remaps keys the same way and can also be fetched using curl.)
I fully understand that changing this fundamental arrangement is NOT attractive to experienced vim users, because muscle memory has long since automatized the arrangement. The old fogey's vociferously defend the old onions for various, mostly self-serving, reasons.
(They tell me, for example, that this will make it impossible to use a vim on a different machine on the same page where they brag about their extensive and brilliant .vimrc customizations that they "couldn't live without." Hmm.)
But I'm starting to teach my kids to use terminals, command lines, and editors, and I didn't want to pass this onion on to their generation. I remapped the keys and retaught myself to make it easier for them. Now we can share the same .vimrc and .zshrc. They'll have one, consistent set of muscle habits for arrowkey motion from the start, whether playing games, editing text, or on the zsh command line.
People always treat hjkl as the single biggest roadblock to vi(m) adoption, and I don't get it. Two points:
* First and foremost: If you rely on hjkl, you are doing it wrong anyway. You should be using f, w, ), :n (for integer n), ^d, ^f, etc. My biggest hjkl use case is using j to idly scroll through a file (or less/more/man page), in which case it's conveniently under my index finger and I love it. I also use l for off-by-one errors.
* Secondly...especially now that it's ingrained, all of the other keys "make sense" (sort of), and there's no excellent alternative. With your setup, "Why is h insert? Wouldn't i make more sense? Gosh, vim is hard to use." Etc. etc.
There are two other advantages to using hjkl, that hardly anyone ever mentions:
1. Ctrl-H is Backspace, one of the most used keys, and much more conveniently placed than, er, Backspace. It's right next to the index finger. It's intuitive (in vim) because H is "go left". Ctrl-H works everywhere, in the shell, in OS/X all over the place, it even works in the Windows shell. It's some sort of fundamental mapping to Backspace such that can't actually be re-mapped.
2. Ctrl-M is Enter, another one of the most used keys, and also more conveniently placed than Enter. As with Ctrl-H, it fits under index finger, it's an ancient mapping, underrated, works in lots of places, even in Windows shell.
If you use the crappy arrow keys, your fingers are totally in the wrong place!
Am on Dvorak and the hjkl doesn't make any sense at all to the dvorak layout. So i have remapped them to snhd instead, but still i end up moving my hand to the arrow keys. But i now think i should try the up down left right layout. i.e Use c instead of 't' that would help eliminate the flow breaker of moving my hand to arrow keys.
I agree, and getting used to using j/k for up and down also offers the advantage that a lot of web apps are supporting it recently.
It is in gmail, google+, github, google reader and probably more, having the habit of using j/k for navigating really helps.
These days, almost all potential vim users have been using the sensibly-arranged arrowkeys for years before they start using vim. Vim puts a second set of arrowkeys right under their fingers, but it has a different, awkward arrangement that makes no sense on a modern keyboard and conflicts with vim's mapping of the real arrowkeys. In vim, the middle finger sits on the DOWN key and reaches up to go up if you are on the arrowkeys (as everyone assumes), but if you are on the home row, your middle finger now means UP instead of DOWN and to get DOWN you go LEFT.
Yet you "don't get" why that might be a problem for people? Really? If it is what you claim, "the single biggest roadblock," then there is something important here, whether you get it or not.
You argue that if you rely on these awkward arrowkeys, "you're doing it wrong anyway." Does that mean they don't really matter? If not, then the using the most prime of the keyboard real estate for operations that "real programmers" don't have much use for would be an even worse design than I'm claiming. If they are important enough to dominate your right hand home row, and I think they are, then your argument is meaningless and they ought to be rearranged so that this no longer "the single biggest roadblock."
And this second reason is silly. Training your finger to reflexively move left instead of up to insert text to the left is going to be a challenge of the same magnitude as relearning arrowkey movement? You think so? People who have been using "copy" for years have to learn that copy in vim is called "yank" and the t,T commands mean, well, "till", and you have all sorts of ctrl-* and meta-* commands to somehow learn, but having to learn to use h instead of i would be such a hurdle that it's really a show stopper for fixing the arrowkeys? That's really your second strongest argument?
These aren't real arguments. Long-time vim users argue that one of the glories of vim is its marvelous customization, but if you customize the basic movement keys, it's supposedly a horror because, well, you then won't be able to use a non-customized vim. So, what's the customization for? It's for secondary things, not something so fundamental. Then you're told by someone else that, besides, if you are using the movement keys much, you're not using vim correctly. Which sounds like a claim that the movement keys just aren't fundamental. And if they're not, what's the problem with customizing them.... What a bunch of nonsense.
It's all a smokescreen for maintaining backward compatibility with a poor design that has spread, mostly in the heads of old programmers (the ultimate "legacy systems"), but also into some software. But for those willing to admit that backward compatibility is the only real argument, think of how much MORE legacy there is these days for the real arrowkeys in the minds of non-vim users and in software of all sorts.
I think vim should change its defaults. It probably would if it were a commercial product, but that won't happen, because defaults in vi/vim are by and for long-time users, not potential users. But it is, as claimed, customizable, and so are most systems (like zsh) that have a significant vi-mode. Systems that don't have a serious vi mode but just toss in a couple of shortcut keys, like j&k, can be learned ad hoc, the way we have to learn all the other shortcut keys that have different meanings in every program.
So, I'm customizing vim & zsh, using the real (physical) arrowkeys occasionally if connecting to a plain-vanilla vim/bash, and it's working out just fine.
In my experience, if you are counting characters or lines in regular vim editing, you are doing it wrong. The smarter jump commands, text objects, and a high key repeat rate are all far superior to counting 20 characters. I do use counts a bit with w/W for words. The main advantage is making your edit in a single command so you can reuse it with dot.
Right, I use w and b to go forward and back one or two words at a time. For lines, I :set relativenumber and use that as a cheat sheet if I want to move or delete n lines down.
Next occurrence of word under cursor is useful. *,#
Learning effective macros is extremely useful.
di" is one of my favorite commands. Delete everything inside the quotes not including the quotes.
Put inoremap jj <Esc> into your .vimrc so that you can press jj quickly in insert mode instead of Esc.
Remap your arrow keys to nop and get proficient with it; this feels like I am editing super fast. A lot of editor time can be spent with your hands on home row without ever leaving.
di" is one of my favorite commands. Delete everything inside the quotes not including the quotes.
You usually want to replace what's inside the quotes, so hence use ci"
cit is pretty nice for replacing a tag's inner html. And of course this works with parentheses - ci( - and brackets - ci[ - and curly braces and single quotes and angle brackets.. I love vim :)
Wow cit...I've been wondering if this exists for a year now. I remember reading about it when I first started learning vim but it somehow eluded me afterwards. Thanks!
I use ci{ all the time for functions and CSS. It's like magic. Whenever I'm using something like nano, I'll instinctively type what looks like a long string of gibberish: "jjjddo [oh crap] <bs><bs>..."
Once you really start getting used to the language, it makes it frustrating to use anything else.
> Wow cit...I've been wondering if this exists for a year now
Then marvel at vim-surround: cs"', cs)(, or cst<foo>, or (Shift-)v select visually S <mytag>, and argtextobj: cia and daa. Those are the two plugins that I really miss on a stock vim.
I normally use C-c. Is there a way to make the time between j...j to be really short? Like the delay for it to count as a double press? I'd like to reduce any chance of accidental typing (although I can't see any reason I'd type "jj" a lot).
You could probably try setting timeoutlen to something like 500 milliseconds (or whatever feels comfortable). Bear in mind though that this is a global setting.
yes you can set the timeout delay to be something very small see :help timeoutlen. It defaults to 1000ms but you are free to change it. If you are typing in insert mode and you press j it will delay but if you press another key that is not bound to anything after j it will just insert the j and the other key.
How could I forget the substitution command? <range> s/old/new/g (g == all occurrences on the line.) range can be a lot of different options. The most useful <range> options in my experience would be:
%(all lines in the file),
select something in visual mode and press :,
-x, +y for + and - x and y lines from where you are.
exact range is not that useful in my daily use.
The other thing to note about the s command is that you can use other delimiters instead of / I like to use #
% s#/some/path/to/a/file#/another/path/#g works just fine and is much more readable than % s/\/some\/path\/to\/a\/file/\/another\/path\//g
>> I don't know how this would work out ergonomically. My dad is a cab driver and he often complains that pressing the clutch with his foot often giving him RSI kind of pain.
I think the car clutch is more related to the force required to press it - it's kind of a long, slow push with lots of pressure AND control at the same time. This seems like a button, on/off-type deal - more like tapping your foot than squeezing a clutch.
CapsLock to Escape is something I find useful with Vim. A lot of people advocate mapping it to Ctrl then using Ctrl-c or Ctrl-], but It's better to just skip the middleman I think.
Another option would be to break apart a wired Rock Band drum kit so it's just the center controller and the drum pad the USB cable comes out of, connect that to a computer and use Joy2Key (or an equivalent) to map the bass pedal to Esc/i. Not nearly as nice, mind you, but if you're sitting on a half-broken kit like I am, it is cheaper.
This one is not quite useful as it works like on/off trigger, but the one, which can be used as a direct replacement of Ctrl-X or Meta-X will be quite useful.
(I am actually Vim user, so I had to ask my Emacs guys on what will be useful with the pedal)
Same, that's why I asked. I know Emacs has various 'modes', like haskell-mode, org-mode, SLIME, etc., but I don't how or if a footpedal would make sense for that. I don't think Emacs users switch between those modes as frequently as Vim users switch between our main modes.
This would actually help Emacs more than vim since you need to hold down the modifier keys while typing commands, where in vim you don't. Several people have done things like this for Emacs but I've lost the links to any info about it.
This reminds me of my friend's father who decided to learn programming later in his life and signed up for a class. Incredulously, their language of choice of Perl, and so not two weeks later he comes back from a class and shows a handout that says:
slkjs/sdfjks/\1jksok/j23kjdj\skjd
is the same as
lkkd\kk////?!@
except latter is shorter and easier to understand
The note was actually correct and the actual expressions made sense, but to an average person both looked like a line noise. Needless to say it was his last class.
My brother made a foot switch using a piece of wood and a sanwa arcade button. I have a couple of teensy boards here, if I get time I may just make one.
I love this. I've felt for awhile that as an industry we should experiment with specialized forms of IO for specific tasks. I've protoyped some devices for rating tracks in iTunes (http://vimeo.com/24298670) and using a joystick to control move through code with a debugger. The keyboard, mouse, and touch screen are great for general purpose IO, but specific tasks can be preformed more efficiently with customized IO devices.
I've been planning to stick an MSP430 inside an old guitar pedal unit for window switching duties. The pedal I have has four switches, I was thinking one for the editor, one for the terminal, one for the browser and one perhaps for firebug or something.
However, maybe these car style pedals would be more ergonomically suited than the little metal studs of guitar pedals, which are designed to be aggressively stamped on.
Haha :D I have actually had the same exact idea. I'm a very keyboard oriented user and I have a wide variety of gaming controllers (including 2 sets of different kinds of pedals for aviation and racing). So I've been thinking about doing a foot operated PC controller, but someone beat me to it.
I'm pretty happy by having my caps lock key mapped to escape, though.
One thing that jumped into my mind when I was thinking about using pedals at the computer is a pedal to switch the current shell into «su-mode». So that commands will be run as root while I'm holding the pedal.
Sadly, I don't think it will be trivial to implement.
I wonder if this would work better as a temporary mode (like how a real clutch works). For example, you stay in insert mode until you press the pedal, which escapes you to command mode, and then restoring insert mode after you depress the pedal?
Thought this myself... BUT it could work with three pedals (i, a and o) with the shift key. Brilliant idea though, I would pay up to $50 for one of these.
You may also want to "c" into insert mode ("cib", "ct:", etc...). I seldom have a problem with this since I usually don't hang around in insert mode anyway (if I'm using gVim the cursor also lets me know).
The one I do have a massive problem with is capslock. So many times I'll go back to normal mode and there's a few moments of disorientation before I realise all my commands are being capitalised. Ugh.
Interesting idea, I wonder about using it for the Ctrl key instead. I switched to vim some time ago and that's the bit I find most clumsy, especially given the placement on a Mac. I've remapped caps lock to Ctrl, which helps.
Just out of interest, how often are you really using the ctrl key in a Vim session? My CapsLock is mapped to ESC, which I hit at the end of every edit (so several times per minute), but I don't think I use ctrl much at all.
OTOH I have heard Emacs users need Ctrl/Alt constantly while editing.
I use Ctrl+[ instead of escape. This has the benefit of having Ctrl easy to reach for the few shortcuts that do use it and also for other programs.
Actually, on the laptop I'm on, I have Caps Lock mapped to backspace - vanilla unedited colemak layout. On my desktop, I have Caps Lock remapped to LCtrl and LCrtrl mapped to backspace.
If you use KeyRemap4MacBook[1] you can map caps lock to Ctrl, but also map just tapping caps lock to escape. Be warned, the only problem with this set up is that it's so good that you'll have trouble using another one; I disabled it when I got a thinkpad and starting doing about 50% of my development on my x220 instead. After that I changed to using ctrl-[ or ctrl-c in place of escape for most everything.
Only problem with ctrl-c is that it doesn't function exactly like escape(for example, if you're inserting text on multiple lines in visual block mode, ctrl-c will only insert the text on one line and cancel the command, whereas ctrl-[ or escape will properly insert the text). If that's a problem for you, you can rebind ctrl-c to actually work as escape. Either way, I find it quite comfortable.
Just know that Ctrl-c is different from Escape. It skips InsertLeave autocmds and cancels the count (i.e., 3aX<C-c> appends 1 'X', but 3aX<Esc> appends 3).
Congrats. I've been thinking for a while to make a clutch for switching hosts file. (I need to switch from testing to production environments for a while) But your idea is much better.
Made one of these to enter and exit strafe mode in Quake, way back before decent mice were commonly available. It worked fine; I put it away when I got my first Razor Boomslang.
Once you used to it the feet will have Vim muscle memory, I wonder how it would effect one's driving especially with the manual gear shifts cars (pun intended :) )
git/GitHub are not for code. They are for version control. Most common applications of git are in software (since things like MS Word et al. have their own implementation of revision history within the software package), but it's not limited to such.
Suppose he comes up with a better way to build the device. It would be good practice to have all versions available, something that isn't as easy to do with a website. Additionally, his target audience is people who use vim, which probably has a reasonably large overlap with git/GitHub users.
I hope that it does not become a trend to create repositories for every blog post. Github is not a personal blog, and I don't think it should be used as such.
Another benefit of hosting something like this on GitHub is you get instant scaling in case you hit the front page of HN (or similar sites) and suddenly get thousands more visitors than some blog software can handle.
Turns out if you have a button to do the same thing, once the user enters immersion the actual control becomes less important. Where alternate hardware is useful is for more analog controls that a joystick/mouse can't easily simulate.
I'll be the one voicing a contrarian opinion here.
vi and vim are holdbacks from the days of 300 to 9600 BAUD modems. A time when more sophisticated interfaces were prohibitive. Back in those days it wasn't too uncommon for people to actually write their own text editors. I wrote a few, mainly in Forth, as I would bring-up self-designed systems.
While I use VIM today when I have to I continue to think that in today's context these things are, well, ridiculous. There is no reason that the terminal can't switch modes on you and allow text editing with the same (or very similar) UI that traditional simple GUI editors provide.
The damn text box I am using in this browser to enter this comment is far more user-friendly than VIM. There is no reason for a modern terminal to continue to support something like VIM.
Put another way, I had editors running on 6502-based 2MHz clock (yes, 2 MEGA Hertz, not Giga) Forth machines that were far more user friendly than VIM or VI. We ought to have better tools today. In my opinion, there is no compelling reason to continue to promote something like VIM. Put a bullet in it already.
As for the hack. Lots of fun. But, geez, how fucked-up is an text editor that you have to come-up with a foot-switch to make it more usable?
> The damn text box I am using in this browser to enter this comment is far more user-friendly than VIM.
Either you're a terrible Vim user or you have a pretty awesome browser text box. I had to install a third party browser extension just to make the damn thing resizeable - woe is me if I want to do search/replace, indent anything, or do anything but the most trivial undo/redo operation. And who hasn't permanently lost stuff they've written into a form by hitting the wrong key?
Yes, I am a terrible VIM user. I have far more important things to do than to get good at using modem-age text editors. My efficiency comes from planning, not counting keystrokes.
Because I am arguing that the purported efficiency gains from the use of vi/vim are insignificant in the context of a non-trivial project. Far more time can be gained (or lost) through activities that have nothing whatsoever to do with text editing.
As an optimization problem, text editing is the wrong aspect of creating a software product to focus on.
Software projects are notorious for being way behind schedule. If the estimate is weeks, it might take months. If it is months, it might take a year or more. In that context, arguing that a text editor will make everyone more efficient is just silly. Get my damn project done on time BECAUSE you are using vi/vim and then I'll drink the cool-aid. Until that happens I will continue to believe that the use of vi/vim is just tribal behavior rather than these tools offering any real business value in the context of a project's timeline, maintainability, quality of code and bug density.
If you can point to a single project that was done on time and without bugs because it was edited on vi/vim then you have a point. I suspect that this is not the case.
>>If you can point to a single project that was done on time and without bugs because it was edited on vi/vim then you have a point.
Software projects are late on schedule for reasons nothing to do with typing speed. Learning text editing is only important for you to make comfortable while you are doing other important tasks.
In other worlds like Java, Intellisense and auto-complete rule the world. You can't do any work sanely without those two things. In fact not knowing them might cause a delay in delivering projects. Using them only brings you on plane with other Java developers. Its a need not an advantage.
<start quote>
Back in 1999, the mag asked Joy what inspired him to write vi:
What happened is that Ken Thompson came to Berkeley and brought this broken Pascal system, and we got this summer job to fix it. While we were fixing it, we got frustrated with the editor we were using which was named ed. ed is certainly frustrating.
We got this code from a guy named George Coulouris at University College in London* called em - Editor for Mortals - since only immortals could use ed to do anything. By the way, before that summer, we could only type in uppercase. That summer we got lowercase ROMs for our terminals. It was really exciting to finally use lowercase.
So we modified em and created en. I don't know if there was an eo or an ep but finally there was ex. [laughter] I remember en but I don't know how it got to ex. So I had a terminal at home and a 300 baud modem so the cursor could move around and I just stayed up all night for a few months and wrote vi.
Linux Mag then asked: "So you didn't really write vi in one weekend like everybody says?"
No. It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow.
9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore.
<end quote>
This is from Bill Joy, who wrote vi. The last line is very much on point and mirrors my point of view: "Now that computers are so much faster than you can think, nobody understands this anymore."
Also: "I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem."
If one was given the task to write a text editor today, even one without a GUI, I would be surprised if anyone reached for some of the things Bill had to do in the context of 300 baud modems and a terminal (not window, but physical).
In the context of large projects vi/vim don't offer any real measurable gains. The fact that programmers who take the time to learn these tools feel good about them does not constitute proof of anything other than that fact.
Editing efficiency, which is what everyone else here is talking about, is (I suspect), completely unrelated to business efficiency (which seems to be what you are primarily talking about). Your Bill Joy quote is talking about editing efficiency.
I do not suggest that editing efficiency has a measurable impact on business efficiency, and I do not see anyone here suggesting that it does.
You seem to be under the impression that when people talk about editing efficiency that they are meaning to imply business efficiency. This is what I was saying when I said you have constructed a straw man.
Unless your programming is a hobby, then it IS business. It sure is to the guy paying the bills.
Imagine a conversation like this:
PROGRAMER: "Hey, boss, on Monday we want to switch to
vi/m because everyone says it is more efficient".
MGR: "Do you have any data to support that? Will the
project get done on-time, on-budget, faster, better
and with less bugs?"
PROGRAMMER: "Well, I can't guarantee any of that and
can't offer quantifiable data, but programmers who know
it swear by it and talk about how much more efficient
it is."
MGR: "It only makes sense to me if you can prove and
guarantee that switching from our current text editor
to vi/m will result in true and measurable productivity
and quality gains. Otherwise there's nothing in what
you are saying that justifies changing over."
Big difference between hobby and business.
Boy, does one have to have a thick skin to voice contrasting opinion on HN sometimes.
Deciding to use an editor is not an event but a process. Its making gradual investments over time, those investments make you productive.
If you are a manager, its worth your time to study tools that help you manage things better. If the best managers in the trade say a particular tool 'x' helps them be productive, then its worth your time to learn that tool. Can you justify minor leaks in productivity while you are learning it day to day. May be no on the shorter run, but the productivity gains over time are going to be so drastically huge its going to be totally worth your time.
If this manager goes to his senior manager and explains all this, I believe the senior manager would understand this. Else these so-called managers are not managers. But glorified desk-supervisors, whose only job is pushing buttons on the blackberry.
And yet, the only thing you know about me is that I am not willing to grind my team of over ten programmers to a halt just to have them learn a tool (any tool, not just vi) that offers no quantifiable code quality or project-level productivity enhancements at all. By some accounts on other threads, mastering vim isn't a one-week stint, it could take weeks.
If you are saying that, in your own business you make decisions that would bring your entire team to almost an absolute without solid business or product quality justification. Well, more power to you. Live long and prosper.
This is hopeless. You clearly have no interest in understanding what others are trying to sayto you. You came here to flame and it seems that is all you wish to do.
That is simply not true. Not one person has offered any data to support the assertions on vi efficiency. Not one. All I have gotten are the equivalent of "because we say so". I am not flaming, I am not caving-in to the bullying, which is a different matter entirely.
In the interest of being constructive I decided to clear the bad blood and start another thread that is designed to educate us who might not understand why some are so passionate about vi. Here it is:
If those who post to this new thread stay within the proposed framework what will come out of it is a set of recipes that show (and support) the claims about vi efficiency. I hope you will be one of the first to join that thread and offer a few examples. There are many who know absolutely nothing about vi. Some have avoided it like the plague. And then, those like me, who only use it when absolutely forced to. This is an opportunity to educate all of us. Thanks in advance. I think it is safe to say that this thread is over (save those who want to talk about the foot-pedal).
I suspect there never will be data, because there's too many variables (including developer skill levels), that measuring 'efficiency' of an editor is a pointless exercise.
I use vim sometimes locally, but almost exclusively remotely, because the context I'm in at the time precludes using 'real text editors' - GUI apps that get installed and have menus and such. If I have to deal with files on a remote box (example: to edit config files), pulling them down to edit in notepad is highly inefficient. Vim is far more efficient - my own data over the last 15 years proves that to me, and generally to other people who watch me, and I say that as someone who really disliked ssh/vim processes - I preferred to pull down files via FTP, edit, save, then FTP up. But efficiency won over after experimentation.
But that's just one context. I use intellij, phpstorm, zend studio and visual studio for different types of editing, and those editors provide a wealth of other tools that make my editing far more efficient in those contexts (development, debugging, creation, testing, etc).
So "vim efficiency data"... likely never to happen, but "eclipse efficiency data" or "emacs efficiency data" won't happen either.
I am in complete agreement with everything you said.
I too have had to administer and support remote systems where vi was the only viable way to edit config files and the like. And, much like you, if I could, I would go for bringing the files into my local system for editing with a non-vi editor (a secondary reason being that if I screwed something up by accident I wouldn't take down a system).
In over twenty years of programming my intersection with being forced to use vi was never frequent enough to warrant spending the time to get good at it. None of my work suffered for it, of course. In my current business nobody uses vi and we get quality work out the door like anyone else. And, I should say, without the need for foot-switches :) --had to throw that in for a little dose of levity.
The damn text box I am using in this browser to enter this comment is far more user-friendly than VIM.
To the average user, sure; the text box is more friendly.
But that's not the point with vim. At all. Vim's design goals are speed and efficiency. To date, non-modal editors haven't come anywhere near vim in that regard.
I think you're missing the point that many developers choose vim over "modern" editors because of its highly efficient text-editing capabilities. The same points could be made about emacs.
As to "user friendly" - depends on who the user is. Yes, this text box is infinitely more user friendly than vim when your mom is using it.
That a foot-pedal might make vim more usable has nothing to do with vim being outdated or unusable. Is your operating system broken / outdated because one might find a food pedal driving "alt-tab" more usable or fun?
If you know vim I'd assume you already know the answer. If you know vim and don't know the answer, I guess vim just doesn't work for you. But for many others, it does. I'm not going to enumerate what's already covered in endless blog posts, SO answers, books, IRC logs, and .vimrcs.
That doesn't really answer the question, does it? The other poster made an assertion about VIM being more efficient. I would like to get a list from him (or her).
Funny enough, not one person is stepping up to the plate to justify and quantify the claims that vi/vim are/have "highly efficient text-editing capabilities".
Numbers. Not statements or links to the manual. I care about data. Show me a project that got done sooner and better because of the use of vi/vim and you'll have a point. I propose that not one person can make that claim and that the popularity of vi/vim are purely tribal.
In this show they demonstrate, among other things, how tribal behavior can be taken to an extreme. It is very hard for some to go against group behavior. They show one example of a guy in a room that stands up when everyone else stands up and he doesn't even know why.
To some extent I believe that some of these tools are like that. You work in a shop where the hot programmer swears by vi/vim and you adopt that without challenging any of it. Very soon everyone is playing the same tune, facts be damned. I happen to be one of those people that does not engage in crowd behavior. This can be a blessing and a curse. I never bothered to spend months on vi/vim because every time I used for days or weeks (out of not having other choices) I came out of it with the distinct idea that the whole thing was just short of lunacy. In the context of the project that needed to be completed these tools offered no real advantages. You are not going to impact the bottom line in any measurable way.
Put another way: If you took two kids that knew nothing whatsoever about computers or programming and set out to teach them. One is taught with modern mostly-GUI tools with "conventional" keyboard shortcuts while the other has to use command line and vi/vim. Both of them have to complete the same project. The vi kid would be absolutely smoked by the other kid in no time at all. No question about it.
OK, how about a second project. Maybe not smoked, but no significant gains would exist out of the vi camp. Programming is far more about things that have nothing to do with text editing. Projects are not late or buggy because of good or bad text editing tools.
I'd still like to see someone quantify the gains offered by vi/vim over the course of a project.
Furthermore, "the other has to use command line and vi/vim. " seems to be confused. Using vi style editing does not really have anything to do with the command line (though it frequently does, that is out of choice, not necessity).
We're talking about a general-purpose text editing tool used by experts for hours, days, and years on end. I understand that you like to click through your menus, but you'll have to excuse those of us who know what we're doing in vim and don't have the time or patience for that.
Your first personal attack was subtle: "I understand that you like to click through your menus"
Now you resort to calling me a troll?
That's nice.
There's nothing unfriendly about a helicopter cockpit. Even if you've only played with flight simulators anyone half-way intelligent can probably figure out most of it within a few minutes. Flying one is a different deal, as mastering and understanding the complex relations between collective pitch, power, torques and aerodynamics. As a simple example, it isn't immediately obvious that flying in ground effect is different from flying above ground effect. Or the interaction between collective pitch, the tail rotor and the demand for power. This is quite different from understanding what the knobs and dials in the cockpit might do.
All of this from simply expressing a contrarian opinion on VIM.
HN does have an unfortunate trait: If you say anything contrary to "tribal" beliefs you get pounded and sometimes brutally downvoted. That does not mean that the tribal belief is right, it just means that there are enough tribe members to bully others into either not participating or simply adopting the tribal memes and falling into compliance. Well, that's not me. If I believe that someone is bullshit you are going to hear it.
Why do I believe that some of the hyper-keyboard-efficiency claims of VIM are bullshit? Because programming is not factory work.
If a programmer is spending so much time at the keyboard that counting keystrokes becomes important they are not doing a good job. I spend far less time programming than I do planning and deciding how to solve the problem. I don't just sit down and start hacking away without direction. By the time I actually fire-up a text editor or IDE to program I have state diagrams, database structures and algorithms pretty much selected and reasonably-well thought out. If I've done such a shitty job at the pre-programming work that my text editor's keystroke count actually matters, well, I'm a hack, not a programmer.
Some of the admittedly interesting things you can do with VI (http://stackoverflow.com/questions/1218390/what-is-your-most...) are, in my opinion, somewhat of a corner case. These are things that one might not do with great frequency. The fact that you can do them is interesting, but that isn't going to be a deal breaker if you only have to do them once every few weeks or months.
In some respects I can derive far greater efficiencies from using a tool such as Excel to sometimes cut hours of coding and formatting by using it intelligently to help generate code that is more maintainable.
One such example is to use it to generate state machine lookup table code that can be copied and pasted into a text editor instantly. I've done state machines with hundreds of states this way. If you do it right they are easy to maintaing and update. No text editor can improve on this level of efficiency.
Another very similar example is to use Excel to help generate JSON files from various tables and data. Easy to setup, maintain and modify. A simple copy and paste into an editor.
When justified, I have taken the time to create more complex tools that automatically generate complex code based on database inputs. One example that comes to mind was a tool to automatically generate all of the code to manage a menu system on an embedded device consisting of an LCD display and a few buttons. Every time the menu structure or content was changed it took days to update the menu processor code. The tool took a month to create. Once in place, almost anyone could generate the code for an arbitrarily complex menu system within minutes. No degree of text editor efficiency can solve these problems.
The point here is that, if I have to resort to counting keystrokes as a measure of programming efficiency then I have either reduced programming to factory work or I am so disorganized that I am spending a disproportionate amount of time typing crap that will have to be fixed many times over before it actually works.
To beat the state machine example to death. In my case it is very rare that I have any bugs when I code state machines, even complex ones. Granted, I've been doing it for a while in both hardware (FPGA's, Verilog) and software applications. Regardless of that fact, this is because I do all of the thinking and planning ahead of firing-up the editor. The resulting code, generally speaking, works on first run.
I've you've ever programmed a CNC machine manually (G-code) you understand this concept. You don't just stand there start hacking away. You take the time to plan it, do all the math, choose tools and verify the approach before you enter the code. If you don't, you'll learn the hard way. These machines are dangerous. I once made a programming error and had my Haas VF3-SS churn aluminum with a 3/4 inch roughing bit like it was butter. Amazing what something with that much power can do. I kept the fucked-up end-mill as a reminder of what not to do.
A professor of mine, who introduced me to APL, took every opportunity to drive a point home. He said that data representation is one of the most important tasks in solving a problem. If you represent the problem using a flawed model it can take ten times longer to create a solution. He pounded that into us to the point that it became instinct. That's why I will never touch a text editor unless I know where I am going. That's my context.
I also caution you and others when considering yourselves "experts" in any field. I learned a long time ago to never utter that word. One can be highly skilled in one particularly narrow area while being completely ignorant of other ideas. I certainly am. I am not just talking programming here. Having access to a larger context is sometimes very important. What makes sense in a myopic context might not make much sense when one is able to pull back to a different plane that covers other schools of thought. Be open minded.
Now, if it makes all of you really happy, down-vote away. It's always fun to watch the tribe in action.
I've noticed that HN is particularly good among online forums about not squashing comments that go against tribal beliefs. Your first few comments, unlike this one, don't contain any justification whatsoever for your assertions. I don't downvote because somebody hates vim and it hurts my feelings. I downvote because somebody hates vim but doesn't feel like they need to justify why, they just want to say it.
Often people who have been downvoted assume that it's just because they've voiced a contrarian opinion, when in reality it's because they've made strong statements with no justification. Then they pretend like they don't care by accusing everyone else of hivemind mentality and proclaiming how much they don't care.
Now onto your argument. You say "programming is not factory work" and go on to say in many words that editing text is not the most important bottleneck in the way of programming efficiency. What surprises me here is that you think that this would somehow invalidate the use of an efficient text editor.
Nobody here is going to disagree with you that the thinking and the designing take more time than the actual typing of those ideas and designs into code. That's not the point. We're not suggesting that vim is solving your thinking problems, and just because vim makes text-editing faster doesn't mean that vim users naturally gravitate towards hacking out solutions without thinking. Nobody is counting keystrokes to measure their entire programming efficiency.
Vim is used for text-editing. Text-editing speed is not the core bottleneck for programming efficiency. You've stated this, but this fact does not at all justify your assertions that vim is a bad tool. Your response above is an attempt to minimize the act of text-editing, as if text-editing itself, rather than vim, is passé and unsophisticated. That is ridiculous. Programmers edit text files all the time, regardless of how smart and awesome their code generation tools are. Those tools don't reduce or obviate the need to edit text, they just provide better leverage; they increase the ratio of work done to the amount of text-editing.
My very first comment gave some (superficial) explanations. I didn't think that I needed to write a small term paper to voice an opinion.
As for down-voting on HN. There's plenty of evidence that it is badly broken. It's funny to watch the Apple fan-boys down-vote on emotion when you even peripherally chafe their idols. The emotion is evident from the fact that substantive posts are down-voted when nothing is materially wrong or offensive about them.
Most of it is also what I call chicken-shit down-voting. No explanation and no reason given. You are accusing me for voicing a contrarian opinion without sufficient explanation. What about down-voting without any explanation whatsoever? I have only down-voted a post once and I went out of my way to explain why I did so. I believe I owe this much to someone if I am going to exercise that right. And so, that is my policy: If I down-vote I have to take the time to explain why. Otherwise I don't do it.
It is clear that the HN culture --at least the one exhibited on this thread-- is that vi/vim are fantastic. So be it. I don't have time to screw around with this topic any more and fend off fan-boy attacks. I suspect the same is true of your case.
I have used a myriad of tools over the years. The only use I have for vi/vim is when I have no choice but to use them. I remember when keyboards didn't even have function keys. In those days these kinds of tools made sense. Today? No. Not any more. You don't have to see it my way. And that's OK.
> they increase the ratio of work done to the amount of text-editing
I would challenge you to quantify that in the context of a real project, concept to completion. I would be willing to wager that vi/vim don't contribute one iota towards the completion of the project.
I have yet to do a project where anyone even remotely said: Wow, that text editor saved us hours of work.
That aspect of the adoration of vi/vim is what I see as ridiculous. I simply don't think that any of it is materially significant to the timeline of any non-trivial project.
Then again, I really don't care to continue on this thread because it truly is a waste of time for all involved. So we are done.
Conclusions:
1- No contrarian opinion of vi/vim will be tolerated by HN vi/vim users.
2- vi/vim are fantastic.
3- Anyone even remotely thinking of suggesting otherwise just doesn't get it.
Trollish nonsense. You haven't even really read my comment, or you'd know that the leverage ratio I mentioned, which you're challenging me to justify, was actually about the efficiency of the tools you yourself were touting, not vim. Your "conclusions" are obviously trolling.
Trolling. Really?
This guy is expressing an equally valid argument. And one that I suspect a fair portion of HN readers agree with.
Personally, I thought it was April 1st when I saw a foot pedal for a text editor!?
Accusing him of trolling is really lowest-common-denominator fanboi bullshit. He makes valid arguments, agree to disagree and move on.
Yes, trolling. Really. In every sense of the word. He didn't even respond to my argument. It's whining about downvotes, about how he doesn't have time for this argument, more repetition of the same irrelevant text-editing-is-unimportant argument that I already responded to, followed by deliberately trolling conclusions. This is not a back-and-forth with points and counterpoints. This is me responding to his points, and him throwing the same shit back like a parrot. I call that trolling.
You think he has a valid argument, cwills? Maybe you can point out to me where he has actually responded to my points.
It should be obvious that it is intended to be useful and educational. No flaming. No trolling. No personal attacks. Just reproducible facts.
I am hoping that you will be one of the first people to post a recipe to that thread so that those of us who don't know enough about vi will, hopefully, see the light.
You've written hundreds, if not thousands, of words in response to this article (about a neat hardware hack lets remember. You've been on a tangent since square one...) accusing vi users of "being tribal" and "drinking cool aid", pounding your own chest, attacking the HN voting system, and in general just doing your damnedest to start yet another editor flamewar.
Then somebody suggests that you are acting trollish, and to you that is simply uncalled for.
As a follow-up to that. When I hire programmers I only care about how well they can reduce a problem to a viable game-plan and how clean and well-documented their code might be. I could not give a crap about whether or not they are 3% more efficient at pounding out keystrokes on a text editor. We waste far more time in other areas than in the mechanics of editing code. In other words, if editor efficiency is adequate and the programmer is really good at hitting the nail on the head, the editor is not a problem. As an optimization problem, the text editor is the wrong place to focus one's attention. It is far more important to create product that is well-written, well-documented (I hate code without comments), easy to maintain and extend.
If you are doing embedded work that involves systems that could cause harm to people or property it is far more important that a programmer understand how to write safe code and take the time to make sure it is safe than to optimize editing speed.
Nothing I have seen in my career justifies contorting ones' brain to learn the commands of a modem-era text editor. It's an utter waste of time when compared to optimizing what really matters.
Your first couple of paragraphs are spot on, but they in no way justify your assertions about vim.
Your last paragraph suggests that learning an editor like vim takes up enough time that it detracts from learning important software engineering principles. I'd like to suggest that learning vim, though scary at first, is not nearly as bad as all that. You pick up more and more of it as you go, and the accumulated bits of time saved over a long period more than make up for the time you spent getting over the learning curve.
"Modem-era"? I assume you don't use any "modem-era" command line interfaces, programming languages, APIs, protocols, or operating systems.
For the record, it's not that text editing 200% faster or whatever will make a significant difference in productivity. For me it's about removing one more impediment that gets me out of the state of flow. And I am more productive in that state. Some people use the Eclipse or Visual Studio shortcuts. I've learned the vim ones, because they're available on more platforms :)
As a side note, the foot pedals are a hilarious idea, but they will in no way improve productivity in vim. Just mentioning it because of your "my editor doesn't need a foot pedal" comments.
"modem-era" is entirely irrelevant. If you have a case to make, it has nothing to do with WHEN something was designed. And it is certainly possible to tweak the keybindings of vim if you need to, it is one of the key features.
If you do state machine code still, check out ragel: http://www.complang.org/ragel/ it's awesome. Since it compiles the state-machine for you, it is much more maintainable than ad-hoc approaches, and as an added bonus will generate state-graphs for you. I used to do the ad-hoc approach to (with an ugly-ass awk script) but since I found ragel, never again!
Would you like programming with a thumb keyboard instead of a full-sized keyboard? That is how I feel typing in a text editor without a vi-like setting. The absence of vi style editing feels unnecessarily crippling.
If you don't feel the same, then whatever; nobody is trying to force vi style editing on you. I don't see what your issue here is, why is it that you seem so intent on discrediting the experiences of others?
People are telling you that they find vi style editing to be beneficial or valuable for efficiency reasons, and you seem to me to be dismissing this. That is what I would call discrediting the experiencing of others.
jlgreco: vi/vim is an efficient text editor when you learn it! And even more efficient with a foot pedal! Don't discredit our time spent learning vi/vim when it is in fact an efficient text editor!
robomartin: vi/vim may be an efficient text editor, but in the grand scheme of a large(non-trivial) project, small improvements to text editing efficiency are irrelevant. Particularly at the sake or cost of learning and mastering vi/vim. There are easier-to-learn and more-intuitive text editors available now.
Sublime Text with vim bindings coupled with zen coding plugin was pretty good for me when coding html/css, till the zen coding plugin appeared for vim.
Now vim has everything I need for coding html/css. To me vim just makes everything better from my experience, it made me more efficient, more faster at coding. Visual Studio with vim key bindings made me love the VS IDE as well haha.
I haven't been using it very long, but the vibrant plugin community (make sure you get BOTH vim plugins) and intelligent shortcuts make it feel like a winner.
A lot of people here complain of RSI and comment how the pedal helps solve that. I tried solving this by creating a keyboard layout especially for vim:
Wow, that's some really badass text editing skills — with a pedal. I imagine one with a piano keyboard with Vim macros attached to each key. That would be dynamic!
VIM is a silly, silly editor for real world purposes
Why do you think that? Vim is perfectly fine for real world purposes - I use it for real world purposes all the time, as do a lot of other people.
Not only do the basic vi commands make my life easier (My mantra is if I have to press the same key more than three times, then I'm doing it wrong - you quickly learn to navigate by words, brackets, lines, search and judge how many of these away you want to move - eg instead of wwwww to move forward five words you can do 5w, to turn "abcde_" into "_abcdeabcdeabcde" you can do 5x3p - silly examples I know, but this makes it very fast an efficient to navigate and edit text), but with vims additional features and with a small handful of plugins there is nothing that a GUI IDE can do that vim can't.
The 1992 paper "The Prevention of Mode Errors Through Sensory Feedback" [1] uses this exact mechanism.
[1] http://research.microsoft.com/en-us/um/people/asellen/public...
I've argued for years that vim is one of the few good examples of modal design since it allows for quick entry of the command grammar without modifiers and the command grammar is an excellent fit for the domain. Whenever I bring this up with an interaction designer, I'm told there is no such thing as a good mode. The citation chain has always wound up at this paper and while I generally agree with the paper's conclusion, I'm frustrated that the editor is used in the most inspid way possible to generate mode errors (at the rate of 3-6 in 10 minutes of editing...). The problem given in the paper is solved by `:%s/\<[A-Z]\+\>\zs/errorerror/g` and I could probably do it a half dozen other ways.
Every time I read the paper I tell myself I should make/acquire a pedal and try it out but I've always been too lazy.