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
· · ·
I figured it’s about time I post an update regarding my emacs journey now that I’ve had some time to acclimate myself to a new way of thinking. This is not so much a blog post as it is just a couple of lists showing where I am in my comfort level with emacs thus far.
I’ve left lots of things off but I think these sum up my current status pretty well. I’m always looking for tips on things I should try, especially on things that aid in navigating around code more quickly. If you have any suggestions please let me know. As always, my current configs can be found on GitHub.
Published on May 09, 2012 Comments
· · ·
Disclaimer: I’m new to the Emacs community so some of the following terminology may be incorrect. Please correct me if there is a more proper way to describe anything I’ve mentioned here.
Over the past few months I’ve realized that I am far too easily distracted from my tasks at work. After a little thinking I came to the conclusion that part of my problem was my work flow. I generally had two or three terminals up bouncing around virtual machines and servers so I could test as I worked and inevitably I would end up on my home server chatting away on IRC for large chunks of time. While most people may be able to correct this with a little discipline, I’ve decided to try something different. One of my coworkers recently made the switch to Emacs and since I’ve always been curious about the features touted by Emacs users I thought I’d give it a try too. I instantly saw a huge difference in my focus and concentration.
Because the driving force behind this change was focus, I have tried to stay away from the typical “Emacs can and should do everything” point of view. There are really only two main features that I’ve been using that go above and beyond a text editor: ansi-term and TRAMP.
As the name suggests, ansi-term is a terminal emulator that can be run inside Emacs. It works almost like any other buffer so moving between normal buffers and the terminal is virtually seamless. This is something I wanted in vim for ages, I even ranted about it here once before.
While it’s possible to open multiple instances of ansi-term, I have limited myself to only having one running at a time. This has helped me concentrate on one task because I am no longer hopping between different terminals with different ssh sessions running. One terminal, one task. Having a terminal in the editor also allows me to do all my scm tasks without leaving Emacs as well, without having to use some fancy git/svn/whatever mode. I just use the normal command line interface I’m used to.
TRAMP is a really poorly constructed acronym for “Transparent Remote (file) Access, Multiple Protocol”. Where the acronym lacks, the execution excels. For you vim users, TRAMP is what netrw really should be. I am able to “transparently” edit files on servers without being nagged about passwords or temp files every time I make a change. This is very convenient for me as I do my development almost exclusively on one of our dev servers. I no longer have to choose between opening an ssh session and editing with the remote editor or using sshfs to mount the remote filesystem locally to get a decent editing experience.
The most important part about TRAMP and ansi-term is that it’s rather
easy to make them work together. Using a tip from the EmacsWiki
I added a few lines to my bashrc to allow C-x C-f to automatically
open up in TRAMP format in the $PWD of the remote machine I’m
connected to in ansi-term. This speeds up the process of opening
files considerably and is pretty much on par with how I worked with
vim previously. The stripped version I use is below.
function set-eterm-dir { echo -e "\033AnSiTu" "$LOGNAME" echo -e "\033AnSiTc" "$(pwd)" echo -e "\033AnSiTh" "$(hostname -f)" history -a } if [ "$TERM" = "eterm-color" ]; then PROMPT_COMMAND=set-eterm-dir fi
Adding this to the remote machine’s bashrc will enable TRAMP to follow the working directory in ansi-term.
There are a couple of features that I would like to dive in to eventually but haven’t looked too much at yet. Having a true programming language at my disposal (elisp) when customizing my editor is very appealing after spending years of dealing with vimscript. I also would like to look in to Org-mode as it may be another tool to help keep me on track at work.
Adding Emacs to my work flow has been great for my development tasks
but I’m not ready to move on completely. I fully intend to continue
using vim when I’m logged on to a test or production machine, and
really any time I’m not doing development. I have been using this
work flow for the past couple of weeks and it seems pretty natural to
me now other than the occasional C-x s or C-x f while in vim.
If you have any questions or suggestions feel free to ping me in the comments or in the usual places. Feel free to watch my .emacs.d grow as I continue to go through this process.
Published on March 07, 2012 Comments
· · ·
For those who may be interested, I’ve created a repo on GitHub where I plan to dump small functions and scripts I write while helping people on irc or on Stack Overflow. In these scripts I will try my hardest to use “best practices” so they can be used as examples when writing your own scripts.
Please let me know if you notice anything you would do differently. The point of this is to serve as digestable examples of proper vimscript.
Check it out at vimscript-snippets.
Published on November 07, 2011 Comments
· · ·
Recently I was searching for a fuzzy-finding plugin to make working with projects a little easier. I posted a quick hack that I still use every now and then, however I’ve recently discovered a rather new plugin called CtrlP.
For the uninitiated, fuzzy-finding plugins allow you to open a file by only typing enough pieces of the path to uniquely identify a file. Sometimes this is as little as one or two characters. I wasn’t really sold on this behavior until I tried using them at work where we have many files with similar names. A plugin like this makes dealing with such situations much easier to deal with than tab-completion alone.
CtrlP is written entirely in vimscript. This is a big plus for me because many of the machines at work aren’t built with +python or +ruby which some of the other fuzzy-finding plugins require. Although it’s written in vimscript it caches directory and filenames for larger directories and can be configured to always use a cache. This means it’s quite slow on first launch in larger directories but is very fast on subsequent calls.
Another big plus is the configurability CtrlP offers. There are (currently) 22 options provided to configure everything from mappings to how caching should work. You can even delegate the file indexing out to a faster external mechanism if you so choose.
Couple all of this with an active and responsive developer that provides excellent documentation and you’ve got my current favorite script.
Published on September 12, 2011 Comments