Articles tagged “rant”

Ctrl-C is not Escape

I’d like to think I’m not one to be pedantic about things, but there’s one common misconception that has been making the rounds that annoys me to no end. Ctrl-c is not equivalent to Escape. There are two key differences that can be demonstrated by the following two snippets.

Ctrl-c skips any pending insert mode abbreviations.

In a vim session type the following:

:iabbrev teh the

This is a common misspelling and an oft used abbreviation. Now enter insert mode and type teh<Space>. Notice that the space completed the abbreviation and it now says the instead of teh. Now do the same but instead insert teh<Esc>. The abbreviation still happens. Do the same with teh<Ctrl-c>. The abbreviation is not completed.

Ctrl-c does not fire the InsertLeave autocmd event.

Dump the following snipped into “cursorline.vim” and launch vim with “vim -u cursorline.vim”.

augroup CursorLine     
    autocmd!
    autocmd InsertEnter * set nocursorline
    autocmd InsertLeave * set cursorline
augroup END
set cursorline

This snippet enables ‘cursorline’ while in normal mode and disables it in insert mode. If you go into insert mode and exit with Esc you’ll notice that the cursorline is re-enabled, however, if you enter insert mode and exit with Ctrl-c you’ll see that it is never re-enabled.

These two things probably don’t seem that important to you, but what about the developers of the plugins you use? If you’re using a plugin that relies on either of these two features you’re risking some functionality breaking by using Ctrl-c. If you must use something other than Escape, use Ctrl-[ instead as these are equivalent.

Published on May 13, 2012 Comments

· · ·

:help shell-window

Run this in vim. The help docs clearly state that vim will never have this feature. That sucks.

But, you say, “vim is an editor! Why should vim include a terminal emulator too? After all, vim is not emacs.” Here’s why: Because developing over ssh with vim is currently a pain in the ass. Sure, there are plenty of workarounds. Using gnu-screen to split the ssh session into multiple shells and/or multiple windows seems to be the most logical since I already use screen. Sounds good but it is horrible in practice…

Consider this situation: I have an ssh session to a server and am running screen in that session.

• I have five screens running: irssi, mutt, ipython, zsh, and vim.
• I select vim’s screen.
• I split the screen and select ipython’s screen.
• I want to read my email so I select mutt’s screen.. but mutt can only take up half the window because I’ve split the window using screen.
• I close the split screen and read my mail.
  
• I want to continue coding so I select vim’s screen.
• I also have to split the screen and select ipython’s screen.

That’s too many keystrokes for such a small convenience. I could remedy the split problem by nesting screen sessions, but that only makes the keystroke problem worse, and that’s only counting what I’d have to do to view the things I want. I’m not sure I even know how to resize or move splits with screen without looking it up.

Now consider the same situation if vim had a shell-window.

• I have four screens running at full size: irssi, mutt, zsh, and vim.
• Inside vim’s screen, I create a vim split with my code in one window and the shell running ipython in the other.
• I want to read my mail so I select mutt’s screen and get a full screen mutt.
• I want to continue coding, so I select vim’s screen and get vim+ipython.

Not only does this simplify the number of keystrokes I have to issue to jump between a full screen mail client and split vim+ipython, it also reduces the number of keybinds I have to remember. I’m already fluent in selecting, moving, and resizing vim splits.. I shouldn’t need to fumble with two sets of keybinds to accomplish the same task in screen.

The good news is I’m not the only one who wants this functionality. In fact, this is one of the most popular features that vim sponsors vote for (along with other IDE like features). There was even an unofficial patch for vim 7.0 that implemented this. Unfortunately I like to keep my software up to date and am not willing to run an old vim and lose features I use to get a feature I want.

So what can I do? There are multiple scripts out there that emulate a shell inside a vim buffer, conque and vimshell to name a few. These are OK, but not great. I applaud the effort put forth by the authors and hope they can continue to move forward with their projects, however I don’t think these solutions are the answer.

Looks like I need to man up and get my hands dirty — someone does anyway. A native vim solution is the only acceptable solution in my opinion. Until I can muster up the guts to dig into the vim source, I guess I’ll just complain to myself.

UPDATE: The author of conque sent an excellent comparison of the available shell options to the vim_use mailing list. You can find it here. I highly suggest subscribing to both vim_use and vim_dev to find out tips and tricks you wouldn’t otherwise know (if you can handle that volume of email).

Published on May 07, 2010 Comments

©2006-2012 rsontech.net