Escape used to be located closer, IIRC it was next to 1 (on `) on some older keyboards. (Much like Ctrl used to be where CapsLocks is now.)
Moving it is easy, of course. Also, Ctrl-[ is usually the same key as Escape, and if you have CapsLock remapped to Ctrl, they're practically on the home row. (The article hints at this, but doesn't explicitly note that C-[ is Esc.) You could also remap CapsLock to Esc, of course.
I'm on a danish keyboard; the programmer-handy keys like "[" and "]" have been moved to shortcuts (alt-9 for "]") to make room for the danish letters "æøå", so some of the combo's that are easy to make on english keyboards are next to impossible on mine.
Once in an effort to reach maximum typing efficiency, i attempted a switch to VIM+Dvorak. However, i quickly realized that i would have to use a Danish variant of Dvorak (there is no official standard..) and remap VIM to oblivion, which would make me too much of an oddball masochist.
A bunch of my coworkers are Swedish, and I've had similar issues with the brackets. It's aggravating.
I use the English/American Dvorak, but it takes me a second to switch back to qwerty as necessary. (I'm probably in the rare niche of mixed vi/emacs users, FWIW.) Vi + Dvorak isn't so bad, though I feel like Dvorak is (somehow) more compatible with Emacs.
I have the same problem, although for a different language, and solved it by using a shortcut (alt-ctrl-k) to switch between layouts (en-us,etc). I do it both on KDE and fluxbox, which are fairly easy to configure and the "mental" switch is not problematic.
This is what keeps me off switching to Dvorak: I have all these keyboard shortcuts wired into my muscle memory that I would have to either relearn or remap when switching to Dvorak that it's just too much of a bother...
vi was developed on the ADM-3A terminal, which indeed has the ESC key in the space occupied by ` these days. It also had Control in the proper place, but the arrangements of some of the punctuation keys on the right side of the keyboard always seemed rather hosed to me.
There are. The Kinesis keyboard has four thumb buttons on each side of the keyboard. The biggest, closest one on the left side I map to CONTROL. The other big left thumb button I map to ESCAPE.
They have two thumbs, but within reach of their thumbs are extra keys. They need these extra keys because there are a lot of characters in their writing. They don't need more thumbs, because they only need to push one of these extra keys at a time.
Do I need more pointer fingers if I need to use one of the Y, H, N, B, T, G, and V keys?
I remapped my keyboard so I can press CTRL with my thumb (it's where ALT conventionnaly is). No need to use pinkies and alternate between left and right CTRL!
I find that Mac keyboards are very difficult to remap. Is there any reason for that? Or maybe there's some utility that handles remapping I just can't find. Buggy as it is, I miss xmodmap.
You can remap the modifier keys (Caps Lock, Alt, Cmd) from the preferences pannel, in Keyboard. There's a button at the bottom, called "Modifier Keys..."
My plan to combat this in any future interviews (and a couple of previous ones) is to bring my laptop with me. If there's any development questions, I'll do it on my laptop. If they become offended that I want to develop in my preferred environment, on my preferred keyboard layout (Dvorak + capslock->backspace), with my preferred editor... they have failed my interview. It ought to be a plus that I came that well prepared.
Incidentally, having been on the interviewing side, I do not see this often enough. Bringing your own laptop ought to be something you always do. I can provide "a" coding environment but it won't be "yours". Unless you always develop in a completely uncustomized standard Visual Studio environment, maybe (in which case frankly I'm still wondering a bit...).
This gets even more embarrassing if you're used to typing in dvorak. I can never remember the actual keys I use to perform certain actions - my fingers obviously know how, but my brain has no longer retained the actual mapping. And I can't just look down at the keyboard to figure out which key it is, since I don't have a dvorak keyboard, just remapped the qwerty one to use the dvorak layout.
For vim users, particularly newer ones, I think the cheat sheet at http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial...
is great. Happy Hacking Lite keyboards are also great - they have the old layout with Ctrl where Caps Lock usually is and Esc not too far away.
As a code composing environment it leaves a lot to be desired until you've tacked on enough plugins that it looses a lot of it's vimmy goodness (imo obviously), as a result I tend to do my first draft in various places (FlashDevelop, the Factor Listener, Dr. Scheme etc...) and then use vim for all the follow up work.
I don't know that it's a failure of vim but I think it's part of the reason articles like this keep getting written. The people not already deeply invested in an editor/IDE (me for instance) are the ones who spend more time writing new code than maintaining or adding to a significant existing code base.
Just my thoughts, not really a comment on the article.
If you mean just vim and not vim + omnicompletion + whatever, then more power to you I guess.
I try to keep my vim pretty vanilla outside of font and color preferences because I spent most of college jumping from one computer to the next and I didn't want to get used to relying on anything that wouldn't be there next week.
That said vim + screen kinda translates to vim + 'my entire computer' which doesn't prove my point really but also doesn't say much about the completeness of vim as an environment.
You can send commands to other 'windows' inside of a screen session. So you can whip up vim plugins to spawn a new screen window (for example) with your test suite running in it. This allows for some of the things that you can do with 'buffers' in Emacs that you can't really do with them in Vim (i.e. you can't launch a test suite in Vim with the output sent to a Vim buffer and still be able to edit with Vim while the suite is running).
That said, I much prefer hex-editing with Emacs to using a combination of xxd and vim.
Could you point me/us in the direction as to how to set this up? I've been trying to emulate this function from Emacs ever since I've seen it in action. I'd love to be able to launch my test suite and have the output available in a buffer.
I've tinkered around with hacks that put shells in Vim windows but it wasn't really satisfactory.
The manpage for screen should tell you how to send commands to the screen session (the -X option, I believe). You just need to create a function/binding in Vim that tells screen to create a new 'window' and run that test suite in that 'window.'
Screen is basically a terminal multiplexer. This would work a little differently if you were using gVim instead of Vim (from within the same screen session that you're sending the test suite command to). If you were using gVim you'd need to use a named screen session (the -S option) and send the screen command to the named session (and possible have logic in the Vim/gVim function to start a named session if one doesn't already exist). Then you'd need a separate terminal window attached to that screen session to view the test suite output.
These articles use the vim+screen combo to send commands to an interpreter, but you can use the same concepts to send your test suite to a screen session.
The "kj" remapping seems like a nifty trick; I've spent a while getting accustomed to ctrl-[ instead of the <ESC> key (I can't reach the <ESC> key without moving my left hand), but it's still hard for me to do quickly and reliably.
The author of the article suggests using Caps lock as control but I've found it's a stellar place to have an escape key. After a few days it felt completely natural for my left pinkie to hit escape. For those on windows, there are a number of batch files that will help edit your registry to remap the keys although I found it to be a problem on Windows 7 until I tried Sharp Keys which worked great.
Another trick that is useful for people who compulsively hit the Ctrl+s keybind from other editors; the following is from my vimrc:
" Map Control+s to save a file
nmap <C-s> :w<CR>
imap <C-s> <ESC>:w<CR>
This leaves you in normal mode which is usually what I want when I hit ctrl+s.
For insert mode I switched to using <C-O> instead of <Esc> after reading that it only enters normal mode for 1 command. That way I stay in whatever mode I was in when I saved.
I actually almost put this in my original post but I didn't know if this was just our server's vim install or if it applied generally. Thanks for the heads up!
Make sure you get function completion, etc for your language integrated in. I know that function is one of the one's non-vimmers seem to miss most when coding, and I'd miss it too, if it wasn't one of the first things I setup for every language.
Most people who use vim don't use it as an exercise in minimalism we're often caricatured as constantly undergoing. I mean, we don't chock it up to Visual Studio/Emacs level of plug-ins, but we definitely use some in our day to day on average.
I use vim in a minimalistic fashion; I've never talked to you about it. My guess is that you haven't talked to other than a minuscule portion of vim-using developers around the globe, and are presenting your prejudice as fact.
Also, a gem that most people don't seem to know about: a standard vim install comes with a program called `vimtutor`. Running it will put you inside vim with an excellent first tutorial, suitable for beginner vimmers.
Good luck! The muscle memory you learn now will pay off in the future! :D
In vim it is the first part of a sequence for manipulating windows. This mindset can conflict with e.g. firefox, in which ctrl-w closes a window. (particularly if there are multiple firefoxes/tabs open)
Edit: That should be close tab, not close window, c-shift-w is window.
It's very useful in situations like this to know that Ctrl-Shift-T reopens the last closed tab, and you can press it repeatedly to continue opening less-recently closed tabs.
Ah. In Emacs, bash, and conkeror, it does something useful.
(I've never really understood why there are keyboard shortcuts for things like "quit program" and "print". How often, if ever, do you want to do those things? Do they really need to be one keystroke away!?)
Thats a pretty inflammatory statement... "In one program and a couple that emulate it...".
How is it not useful to have a keyboard shortcut to change focus between windows? Windows in vim refer to what I believe are called "splits" in emacs. The vim c-w stuff is analogous to c-x stuff in emacs.
As for close tab shortcuts in firefox -- I use it all the time. Standard work flow for me includes c-t, google.com, <misspelled word>, c-w, <correct spelling from "did you mean">.
Ugh. I keep looking for a way to turn this "feature" off. The fraction of a second it would take me to recognize and correct my mistake is far less frustrating and time-consuming than having to parse the message and select an option.
Of the hundreds of times this feature has popped up, I believe I've actually hit "y" twice.
">" is the indent command. Repeat it ">>" to indent the current line. Use any other vim ranging construct (e.g. ">2j") to indent wider ranges--i.e. the current line plus two lines below.
"=" is the autoindent command. Vim recognizes many languages and you can give it plugins to understand more. Use "==" to autoindent the current line. My personal favorite, "gg=G", jumps to the top of the document and autoindents the entire thing. One time at work I was gently reminded how many spaces I was supposed to indent per the company's coding standard. I quickly set the relevant editor parameters and with four keystrokes my code was compliant.
I think there's a code-folding ability but I've never used it.
Indenting? Heck yes. '=' will indent for you. You just have to give it a movement.
=j means 'indent this line and the next'
=% means 'indent to the matching brace'
=/foo mean 'indent to the next occurrence of foo'
1G=G means 'go to the first line and indent until the last one'
If you want specific rules for indenting file types, you can put stuff in your .vim/indent/ folder to define them
The problem comes when you don't know what the topic you're looking for is called in vim. I've only had that problem once or twice over the years, but it can be frustrating (esp. w/ no Internet connection).
I agree. Fortunately however, :he has tab completion, which certainly reduces such. Also :he index is nice. And for those times with internet, #vim on freenode usually knows the correct :he keyword in seconds.
Depending on the area you want to indent, you can use visual mode with % to select the block and then >> it over, or, for more specific regions, use visual block mode with ctrl-V to highlight the first column of the text you want to indent, hit I, indent the line by hitting space, and hit escape. When you move the cursor the other lines will indent.
I like how people think vim is vi, and talk about vim-specific features as though they are in all vis.
Incidentally, I sometimes use vim as $EDITOR when dealing with perforce, because if the editor dies (or fails to start) for any reason, all changes are committed by default with no commit message... and sometimes I don't have an emacs for emacsclient to connect to. (The result is 30 minutes of work trying to get perforce to uncommit my changes. Usually I fail and just comment out the tests, commit that, and fix the code later. Ah, perforce...)
Anyway, I recently discovered that C-p, C-n, C-b, and C-f work as they do in Emacs. They just need to add C-a, C-e, M-m, C-k, and C-y, and normal mode will become unnecessary. (And I won't need to install mg on so many machines.)
And then vim will almost have as many editing features as my bash prompt ;)
Editing is a large but incomplete part of programming, which is why vim is a large but incomplete part of my programming environment.
Look, if you're arguing this just to take potshots at "that thing you don't like" then we should end this conversation now. If you're open to the possibility that we can both be productive with different toolsets then I'd like to learn more about your setup and maybe share some of the benefits of mine.
Ah, too bad---I was hoping for an article on why to stay the hell out of insert mode, not how to. I know how to; I sometimes have a hard time convincing my students that it's good for them to become power users of their editor, and thought this might be a link I could pass along.
I use ViEmu in Visual Studio as my primary "vi editor", and the clashing of Visual Studio and vi really adds up after a while. As I'm sure you can guess CTRL+O and CTRL+C don't work in ViEmu.
I think the real solution is to make vim my main editor for working in C#. That's a pretty tall task unfortunately.
Yeah, part of me is not convinced ViEmu is the way to go. So many things in VS still require either the mouse or the arrow keys. A simple example is intellisense, once it pops up, j/k are not going to scroll through it.
I've remapped caps lock to ESC, which I think is a far better use of that useless button, and a hack i recommend to everybody i know who uses VIM.
I could never understand that VIM choose to put such an important button so far away from the homerow.