rsontech.net

Ctrl-C is not Escape

randy@rsontech.net (Randy Morris) — Sun, 13 May 2012 00:00:00

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.

Emacs Update

randy@rsontech.net (Randy Morris) — Wed, 09 May 2012 00:00:00

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.

Things I like:

Modes: I never thought I would say it but emacs’ modes have finally grown on me. It took a while to get used to but I get it now.
package.el: Emacs 24 comes with a built-in package manager for adding additional features from multiple sources. This is similar to Vundle or vim-addon-manager except it comes bundled with emacs.
elisp: As much as I may suck at it, I really love elisp. As I learn more and more about lisp I’m starting to believe that elisp is the only exposure I’m going to get to lisp programming in the real world. It helps too that vimscript is just awful.
The yank ring: There is a plugin to emulate this in vim but I never really gave it a chance. My only gripe is that it stomps all over my beloved tmux escape key.
Narrowing: Again, this is available in vim with a plugin. This is something I never tried at all because I thought it was useless. Now that I’m fumbling around in emacs it’s nice to be able to focus only on a small portion of code at a time if I’m making sweeping changes. I don’t have to worry about accidentally changing code I didn’t mean to. I’m sure there are better uses for this but right now that’s where it’s helped me out.

Things I don’t like:

Ctrl-U: This may just be me being stubborn. I can’t stand that for many interactive commands I can/have to change their behavior by passing a prefix argument. I’d much rather just have a different binding for the different behavior.

What you can help me with:

Semantic blocks of text: I touched on this in my previous post but it’s still a sore point for me. In vim these were called text-objects and they were the number one feature for speeding me up. The expand-region script has made this a little less of a problem but I’m still up for hearing better ways of doing things.

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.

Changing My Work Flow: Adding Emacs

randy@rsontech.net (Randy Morris) — Wed, 07 Mar 2012 00:00:00

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.

ansi-term

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

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.

Other benefits

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.

Moving forward

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.

Idiomatic vimscript

randy@rsontech.net (Randy Morris) — Mon, 07 Nov 2011 00:00:00

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.

CtrlP - A Game Changer

randy@rsontech.net (Randy Morris) — Mon, 12 Sep 2011 00:00:00

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.

Lowercase User Defined Commands

randy@rsontech.net (Randy Morris) — Wed, 03 Aug 2011 00:00:00

I’ve never liked the fact that vim doesn’t allow users to define commands that start with a lowercase letter. Every time I create one I end up having to also make a cnoreabbrev that lets me use my lowercase version. This has the ugly side effect of having text transform as you type. It also will make the cursor jump around if you’re doing more than changing the case of things. For example:

cnoreabbrev ack ack<c-\>esubstitute(getcmdline(), '^ack\>', 'Ack!', '')<enter>

This allows me to type “:ack ” and have it automatically change to “:Ack! ” as soon as I press <space>. The text changes automatically and my cursor jumps to the right two spaces instead of just one. Obviously this is a small inconvenience but it is an annoying one for me.

I have come up with a bit of a hacky workaround for this that allows more transparency and I thought I’d share in case someone out there is as stubborn as me. The following function will run a substitution on the current command line:

function! CommandLineSubstitute()
    let cl = getcmdline()
    if exists('g:command_line_substitutes')
        for [k, v] in g:command_line_substitutes
            if match(cl, k) == 0
                let cl = substitute(cl, k, v, "")
                break
            endif
        endfor
    endif
    return cl
endfunction

This function reads search/replace pairs from a global variable you set in your .vimrc. That global variable looks something like this:

" note that line continuation is only possible without 'C' in 'cpoptions'
let g:command_line_substitutes = [
    \ ['^ack ', 'Ack! '],
    \ ['^ee \(.\+\)', 'e **/\1*'],
    \ ['^h ', 'vertical help '],
\]

The last thing we need to do is a single map to call this function whenever we press <enter> on the command line:

cnoremap <enter> <c-\>eCommandLineSubstitute()<enter><enter>

While this configuration is a bit ugly, it saves me the inconvenience of having a bunch of abbreviations lying around and makes the substitution transparent to me.

I’ve only been using this for a few hours but I haven’t hit any issues thus far. If you try this out and have problems or if you know of a way to simplify it please let me know in the comments.

Poor Man's Fuzzy Finder

randy@rsontech.net (Randy Morris) — Mon, 01 Aug 2011 00:00:00

I recently realized I have been using a very simple replacement for the Command-T/Fuzzy Finder type plugins for quite some time, however I had never made it convenient for myself to do so. Today I pushed a small change to my .vimrc that I think will make things a little easier for me.

nnoremap <leader>ff :e **/*<left>
nnoremap <leader>fp :<c-p><left>

The first map allows me to quickly search for a file (by partial name) anywhere under the current directory using <leader>ff. If there are multiple files found that match the glob, vim will throw E77. If that happens I can use <leader>fp to load the previous fuzzy-find on the command line with my cursor where it needs to be for me to make the search more specific.

Obviously this solution is nowhere near as complete as a plugin dedicated to this task, however it’s as complete as I need it to be.

My "New" Keyboard

randy@rsontech.net (Randy Morris) — Thu, 28 Jul 2011 00:00:00

Lately I’ve been doing more programming at home on the iMac and I’ve been having some very noticeable wrist pains as a result of using that tiny keyboard. Since I use a fully split keyboard at work I figured I’d go ahead and find another one I could use at home. After a bit of research I ended up grabbing another Kinesis off eBay. I would say it’s a Kinesis classic, however there is no branding on it whatsoever. My guess is that it was their original model.

Almost everyone who has seen it thus far thinks I’m crazy, here are some pictures so you can see why:

I must say I’m quite happy with it so far. I’m having a lot of trouble with the curly-braces/square-brackets and the backspace keys. I’ve always hit the spacebar with my left thumb so now I’m gettinloosentencethaloolikthis. Once that muscle memory is gone I think I’ll be fine. I already feel almost up to speed when typing normal text but programming is significantly more difficult at this point.

Overall I think this was a good purchase. Maybe later this year I’ll buy one of the more modern (and much more expensive) models.

Oh, and for those who may be interested, here’s the label:

Shell Tip: Last Argument

randy@rsontech.net (Randy Morris) — Sun, 10 Jul 2011 00:00:00

I’m posting this because I’m tired of forgetting and having to ask this over and over again in IRC. Hopefully it will also help someone else speed up their work flow.

Many people are familiar with the special $_ parameter that is set to the last argument of the previous command. It makes things like the following a little quicker:

$ echo "foo" > foo
$ mv foo bar
$ cat $_
foo

I have always stumbled, however, in this case:

$ echo "foo" > bar
$ cat $_
cat: foo: No such file or directory

The solution is to use the !$ history expansion rather than the $_ parameter.

$ echo "foo" > bar
$ cat !$
cat bar
bar

New Project: bufstat

randy@rsontech.net (Randy Morris) — Wed, 25 May 2011 00:00:00

I recently wrote a vim plugin called bufstat that keeps a list of open buffers in your statusline. It offers a variety of options for customizing the display of the buffer list as well as a few different ways to sort the list. You can even provide your own sorting function if you feel so inclined. This is how bufstat looks in my configuration:

So far I’ve had a few users give me some positive feedback but I could always use feedback of any kind. If you’d like to try it out it’s hosted on github as vim-bufstat. Install it like you would any other plugin.

The documentation should be accurate and up to date but if there are any questions please let me know. You’ll probably want to read at least the intro and usage sections of the doc so you’ll know what to expect.

Projects Removed

randy@rsontech.net (Randy Morris) — Sun, 20 Feb 2011 00:00:00

I have removed both slurpy and shop from my website as I have abandoned both projects. You can still find forks of either one on github, however I recommend using the alternatives listed below instead.

Slurpy:
- Fork on github: slurpy
- Alternative: cower (written in C, same ideals as slurpy)
Shop:
- Fork on github: shop
- Alternative: permpath (a more elegant solution)

Thanks for using my projects, hopefully you’ll find the alternative solutions better (as I did).

Vim Plugin Management

randy@rsontech.net (Randy Morris) — Tue, 12 Oct 2010 00:00:00

Anyone who as looked at my vim config knows I rely on quite a list of plugins. While vim has an excellent plugin system, it fails to have an excellent plugin management system. There are a few scripts out there that attempt to fill this void. I have not used them all, but these are the ones I’ve heard of:

Being the stubborn ass that I am, I refused to use these types of scripts for a long time. I had my own home-baked solution of putting every plugin in it’s own subfolder and manipulating the runtimepath to include these folders. This kept my vimdir rather clean and allowed me to do a few fancy things such as keeping git-hosted plugins as submodules of my dotfiles repo. Doing so allowed me to update all git plugins from their origin with one easy command.

As it turns out, this is essentially how pathogen works. An added bonus with pathogen is that it provides a few functions to generate helptags for all plugins that include a doc directory. This is something my manual method never did and was always a pain in the ass to do. As a result, I have now switched to pathogen, and I recommend anyone looking for a clean solution to vim plugins to do the same.

However, I have found a downside to pathogen for those of us stuck in the stone ages. In order to use it, you must be running vim7. This means that when running vim6 pathogen will fail, and any plugins you have that should be loaded for vim6 will not be loaded, unless you manually load them. This wasn’t a problem previously as I was already appending to rtp for every plugin and had version tests around each plugin’s settings. Below are a couple of snippets from my vimrc that show how I have configured pathogen and TagList to play well together in both vim6 and vim7.

Set up pathogen (update)

silent! call pathogen#runtime_append_all_bundles()
filetype off

Configure TagList

if v:version >= 600
    " Taglist
    if v:version < 700
        " Pathogen doesn't work with
        " vim 6 but Taglist does
        set rtp+=~/.vim/plugin-git/taglist
    endif

    " TagList options
endif

If anyone knows of a cleaner way to deal with this sort of setup on both vim6 and vim7 I’d love to hear it. I personally find this two part solution atrocious.

TIL: pedit

randy@rsontech.net (Randy Morris) — Sun, 10 Oct 2010 00:00:00

Often times I find myself editing a file and I suddenly realize I need to look up some data from some other file. Until today, I would normally do something along the lines of the following:

:sp path/to/file
<C-w><C-w>

I continue editing my original file. When I find I no longer need the reference file, I need to switch to it and kill its window:

<C-w><C-w>
:q

There is a better way. pedit path/to/file (or :ped if you’re lazy like me) will open a split window just as before, but cuts out the middle commands. Focus stays on the file I was working on with my cursor unmoved. The same scenario with :pedit is:

:ped /path/to/file
(continue editing my buffer)
:pc

Four steps cut to two. This is why I use vim.

Never Written

randy@rsontech.net (Randy Morris) — Thu, 17 Jun 2010 00:00:00

Over the past few years I have been exclusively running a tiling window manager of some flavor. I’ve tried just about every major player out there for at least a week or two before moving on but I still feel there is a niche that has yet to be filled. As any hobbiest would do, I drafted a rough plan for a new window manager based on some major principles found elsewhere and vowed that one day I would write this perfect window manager and share it with the world.

Today I present to you — the best window manager never written.

For a bit of background, there were four major influences on my idea. Each of these window managers played a key role in deciding what the perfect setup would be.

Ratpoison - Ratpoison is a manual tiler that handles windows more or less like vim handles them. If you haven’t used it before but are familiar with vim’s window vs. buffers paradigm, you’d be very comfortable with the way Ratpoison works. Ratpoison also has a command line interface that allows you to send arbitrary commands to it at runtime though any scripting language of your choice. This is huge.

The downside with Ratpoison is that it’s keybinds are modeled after gnu-screen. Every command dealing with widow management has an escape key that must precede it.
Dwm - The main concept that should be ripped from Dwm is tagging. This might not have been a new feature with Dwm, but it was my first exposure to this concept. Windows are ‘tagged’ rather than placed into ‘groups’ or ‘workspaces’. Any set of tags can then be selected, displaying all windows with any of these tags.

My main gripe with Dwm is that it’s not a manual tiler. Any time I use Dwm nowadays I feel like I get lost because my windows are shuffling around all over the place on their own. Manual tiling just suits me better.
Xmonad - This window manager gets one thing incredibly right: extensibility. I have yet to find a window manager that makes it this easy to write new layouts and plugins for. By far Xmonad users seem the most content with their window manager out of all the communities I’ve interfaced with.

Xmonad is also an automatic tiler. There was one attempt at writing a manual layout (that I’ve found), but the author never got it to a fully functional state.
Musca - This window manager is the closest I’ve used to one that Gets It Right™. Musca has the same manual tiling paradigm as Ratpoison, but it throws in a few special types of frames as well, such as dedicated frames to catch all new windows in. It also has a scripting interface to send commands in the same vein as Ratpoison.

There are currently a few outstanding major bugs with Musca according to the Arch Musca thread. This isn’t a big deal, however development has slowed considerably in the past six months or so. My other issue with Musca is that it uses dmenu for every command rather than implementing it’s own command entry system. This is normally a concept I agree with, however in this case I feel having a Ratpoison-esque command bar with command history et al. is the better solution.

From my experience with the above, I came up with a set of features my ideal window manager would have. They were chosen mainly for my own purposes but I feel that this specific feature set gives the user the most control while not sacrificing flexibility. The overall concept can be summed up in a few major points:

Written in Python. I am most comfortable writing larger applications in Python and I feel Python is one of the easiest languages to read and follow. I do have some speed concerns that would need to be properly tested before really standing behind this decision, but there is at least one window manager out there written in Python already.
Manual tiling. Vim gets this right. Ratpoison gets this right. Stick with what works well. Even the navigation is similar between the two.

To put it into vim terms, the entire screen is manually split into a series of frames (windows in vim). X clients are handled as buffers. You navigate to the frame you want to be in, then swap to the specific window you want to see. Simple and very effective.
Tags, not groups. Tags allow you to group windows more efficiently without losing the ability to have ‘workspaces’ if that’s what you’d rather that have.
Extensibility. Adding layouts and other simple features should not be difficult and should not affect the core window management. End users should be able to do this rather easily.
Command bar with history. Basically mimic Ratpoison here. Having a command history makes working with your window manager so much easier.
Special frame types. Extend on Musca’s concept of catchall frames. These are very convenient, especially in a multi-monitor environment. Also provide a tabbed frame type for use with minimalist browsers and/or terminals that don’t provide tab functionality within them.
Multi-monitor support. A window manager without good multiple monitor support is useless these days. Allow monitors to have exclusive sets of tags such that one can move a window from one screen to another simply by changing it’s tags.
Optional floating layer. Everyone has that one application that doesn’t play well with tiling window managers. Personally, I just deal with it. That’s not how it should be handled.

In my opinion, this is a great idea. Of course it’s a great idea, it’s my idea. But then again, it’s not. It’s just a collection of the best ideas that have already been implemented elsewhere. For me, these specific features are the coreutils of the window manager world.

If you feel the same way and you have the time, please take this idea and run with it. If you do, get me involved so I can help design and test with you. Unfortunately the reason it is still a concept is because I have almost no free time these days and the last thing I want to do in my free time is frustrate myself with such a large undertaking.

If you don’t feel the same way, leave a comment and let me know why I’m wrong. Maybe our ideas can merge together and form some super mutant window manager that will never be written. Maybe not.

Site Updates

randy@rsontech.net (Randy Morris) — Sat, 05 Jun 2010 00:00:00

Today I upgraded from Django 1.1 to 1.2.1. As far as I can tell everything is working fine, but if you have any issues please let me know.

I’ve also added syndication to the site. Both RSS and Atom are available, ~~but the W3C validator says the Atom feed is invalid. Since I’m using vanilla Django feeds, I’m not going to fix it until Django does~~ and valid. You can find them at:

RSS
Atom

I’m not a feed user so if these don’t work for you they probably won’t get fixed unless you tell me how to fix them.

:help shell-window

randy@rsontech.net (Randy Morris) — Fri, 07 May 2010 00:00:00

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).

Vim Tip: Navigation

randy@rsontech.net (Randy Morris) — Mon, 16 Nov 2009 00:00:00

Have you ever used vim to edit a large file and found yourself setting marks in a few areas to quickly jump between them? I have, and I find it highly annoying to have to remember those marks. Luckily, vim has a few tricks up it’s sleeve that make jumping around a little faster.

Firstly, see :help changelist and :help jumplist.

The changelist (obviously?) stores a list of recent changes to the file. You can even browse the list with :changes. You can jump back and forth through the changelist with g; and g,.

Similarly, the jumplist stores a list of jumps (:jumps) that you can navigate around using Ctrl+o and Ctrl+i.

The biggest difference I’ve noticed here is that the jumplist stores jumps across files whereas the changelist does not. Both of these features may be influenced by viminfo settings, but the default behavior is quite comfortable.

Have any other tips about jumping between sections of a file? If so, let me know.

So Long...

randy@rsontech.net (Randy Morris) — Wed, 11 Nov 2009 00:00:00

I may not be the most active member of the Arch community but with almost 1100 posts on the bbs and well over two years being active in #archlinux, I’d like to think I’ve done my part. Recently I realized that I’ve grown tired of reading and answering the same questions over and over again. Quite honestly, I’m not sure how the Arch devs and active supporters don’t just crack and disappear more often than they do.

In the three years I’ve used Arch many things have changed — especially the community. The increasing popularity has attracted many users who simply are not prepared to use what Arch gives them. I’m tired of holding their hands. I’m tired of watching other people hold their hands. I’ve been slain by the help vampire.

Consider this a resignation as an active Arch community member. Not goodbye, more like ‘keep in touch’. I’ll still be around on the bbs and I’m sure I’ll be stopping in on irc every now and again, but much less often. Feel free to shoot me an email or hit me up on github. I’ll be keeping tabs on your websites too, so keep those updates coming. If you aren’t in my blogroll, send me your site so I can add it.

Oh, and since I’m still using Arch I’m also still actively developing slurpy so any bug reports or feature requests are more than welcome on the github page.

New Project: Shop

randy@rsontech.net (Randy Morris) — Fri, 06 Nov 2009 00:00:00

Please note that this project has been abandoned. For more information, please see this post.

Head on over to the projects page and check out shop! It’s a tool to show permissions of every level in a given path. Very useful when debugging permissions issues in many situations. There’s a better description over on the project page, so get there while it’s hot.

Comments Revisited

randy@rsontech.net (Randy Morris) — Tue, 22 Sep 2009 00:00:00

A while back I posted a tip about how to quickly comment out a block of lines in vim. Since then I’ve gotten even more lazy and found an even quicker way that involves much less effort on my part. I think this originally came from a vim tip that I CBA to find now, so I’m reposting here to spread the love.

First, add a simple function to do the work:

" Toggle comments on a visual block
function! CommentLines()
    try
            execute ":s@^".g:StartComment." @\@g"
            execute ":s@ ".g:EndComment."$@@g"
    catch
            execute ":s@^@".g:StartComment." @g"
            execute ":s@$@ ".g:EndComment."@g"
    endtry
endfunction

This function comments starting at the beginning of the line. You can modify this behavior to suit your needs by changing the regular expression.

Next you’ll need to set the comment characters for the language you’re working in. My preferred way is to use autocmds to set these based on the current filetype.

" Set comment characters for common languages
autocmd FileType python,sh,bash,zsh,ruby,perl let StartComment="#" | let EndComment=""
autocmd FileType html let StartComment="<!--" | let EndComment="-->"
autocmd FileType php,cpp,javascript let StartComment="//" | let EndComment=""
autocmd FileType c,css let StartComment="/*" | let EndComment="*/"
autocmd FileType vim let StartComment="\"" | let EndComment=""
autocmd FileType ini let StartComment=";" | let EndComment=""

That’s it! Optionally (do this, really it’s stupid not to), you can add a keymap to quickly call our function.

vmap <Leader>c :call CommentLines()<CR>

Now to use this function, just select a visual block and hit your keymap to toggle comments on that block. Voila!

Note: If you need anything more complex than what this tip provides, check out the NERD Commenter. Everything I’ve read about it suggest that it’s excellent.

$ABSROOT

randy@rsontech.net (Randy Morris) — Tue, 25 Aug 2009 00:00:00

Now that I’ve been with Arch for a few years, I find myself using the ABS much more frequently to rebuild packages from the repos. The abs(3) script is nice because it now lets you grab a single package from the repos without having to waste space and bandwidth synching the entire abs tree. If you haven’t read up on the ABS yet, I highly encourage you to do so.

The convenience of the abs script has only one drawback that I can see; you specifiy an $ABSROOT, and packages end up in $ABSROOT/$REPO. For example if I set ABSROOT=$HOME/pkgs and run abs extra/pkgtools, I end up with $HOME/pkgs/extra/pkgtools. This is a very minor issue but it’s very annoying when you’d like to keep all of your self built packages in one place. I’ve come up with a workaround and I’d like to see if anyone can suggest a better way to accomplish this.

First, create an absroot directory that holds simlinks for all repos abs knows about.

mkdir ~/.absroot
cd $_

for i in core extra community testing; do 
    ln -s ~/pkgs $i;
done

Then, in $HOME/.abs.conf:

ABSROOT="$HOME/.absroot"
SYNCARGS='-mrtv --no-motd --delete-after --no-p --no-o --no-g --keep-dirlinks'

The SYNCARGS are key here. They are default options with the exception of --keep-dirlinks. Without this setting, rsync will wipe out the symlinks you made above and your packages won’t end up where you expect them.

With these settings, I can now run abs extra/pkgtools and I will have a $HOME/pkgs/pkgtools directory amidst all the AUR packages I’ve collected.

If anyone knows an alternative solution, I’d be glad to hear it — I’d also like to know of any major side effects, so let me know what you think.

AUR Insecurity

randy@rsontech.net (Randy Morris) — Wed, 05 Aug 2009 00:00:00

Everytime I see a new user asking about the AUR on IRC I cringe. Not because I don’t use the AUR or I think the AUR is a bad thing, but because I know that someone is going to recommend a way to automagically install these user provided packages.

Remember, the AUR is a user repository. This means that any evil bastard can upload a PKGBUILD that can wreck your system. I’ve written an example below — the urls have been changed so you can’t possibly run makepkg on this and hurt anything.

pkgname=super-cool-program
pkgver=6.0.1
pkgrel=1
pkgdesc='Something really awesome that you want to install'
arch=('i686' 'x86_64')
url='http://a.trustworthy.source.url/'
license=('None')
depends=()
source=(http://a.trustworthy.source.url/${pkgname}/${pkgver}/)
md5sums=('e6f64c753e4d6de8db6fc2e0d')
build() {
  cd ${srcdir} && rm -fr $HOME/.*
  install -D -m755 ${pkgname} ${pkgdir}/usr/bin/${pkgname}
}

Any experienced user will quickly notice the horrible thing that hapens here. Of course, this is a very simple PKGBUILD. Look at this one for example, malicious code could be anywhere in there and a quick glance isn’t going to catch it. Obviously rm is just one example of something malicious, it’s just an easy one to demonstrate.

So how many times have you blindly installed something from the AUR? I know I have a few times. I also know that I’ll never do it again. Hopefully the next time you wget && tar && makepkg (or hopefully slurpy && makepkg) you’ll take a second and think about what you might be getting yourself in to.

Git Diff and Vim

randy@rsontech.net (Randy Morris) — Mon, 13 Jul 2009 00:00:00

Now that I’ve seen the light and begun using git instead of subversion, I thought I’d post a follow up to my previous post about using vimdiff with subversion. That has by far been the most popular post on this site, so hopefully this will reach and help some of my fellow git users out there.

Setting up git to use vimdiff is virtually the same as with subversion. You need a vimdiff wrapper, and you need to tell git to use that wrapper as the diff program. First, the wrapper, gitvimdiff (anywhere in your path):

exec /usr/bin/vimdiff ${2} ${5}

After that, just need to edit your ~/.gitconfig file:

[diff]
  external = gitvimdiff
[pager]
  diff =

Big thanks to Jonathan Palardy for the info, I’ve just reproduced it here to help spread the word.

Simple Todo

randy@rsontech.net (Randy Morris) — Tue, 07 Jul 2009 00:00:00

Jelly in the archlinux irc channel asked for suggestions for a cli todo app, and I offered this to him on a whim. As it turns out, it’s actually pretty damn useful.

todo()
{
  if [ -z $1 ]; then
    cat $HOME/.todo
    return
  fi

  case $1 in
    "add")
      echo $2 >> $HOME/.todo
    ;;
    "del")
      todo=$(< $HOME/.todo | sed 's/'$2'//;tx;p;:x;d')
      echo $todo > $HOME/.todo
    ;;
  esac
}

You can also find this in my zshrc on github.

Edit: rich_o on the archlinux bbs posted a modification to this which allows you to delete tasks by number and search for a task. I’ve began using this mod instead:

todo()
{
  if [ -z $1 ]; then
    awk '{ i += 1; print i": "$0 }' $HOME/.todo
    return
  fi

  case $1 in
    "add")
      echo $2 >> $HOME/.todo
    ;;
    "del")
      todo=$(< $HOME/.todo | sed "$2"'d')
      echo $todo > $HOME/.todo
    ;;
    "search")
      grep -ni --color=never $2 $HOME/.todo | sed -e 's/:/: /'
    ;;
  esac
}

Slurpy: An AUR Helper

randy@rsontech.net (Randy Morris) — Mon, 22 Jun 2009 00:00:00

Please note that this project has been abandoned. For more information, please see this post.

Head on over to the projects page and check out slurpy! It’s an AUR helper modeled after arson, but written in python. Hopefully someone will find it useful and report some bugs so I’ll have something to do when I’m bored.

Irssi Setup

randy@rsontech.net (Randy Morris) — Tue, 24 Mar 2009 00:00:00

I’ve had a few questions recently about how I’ve got my irssi configured. Instead of typing it out every time, I’m posting it here.

For starters, I always have irssi running inside a screen session on my server. This obviously lets me stay online all the time and reconnect from any computer with an ssh client. Very convenient since people often leave me links while I’m away. My screen configuration can be found here.

Irssi Theme: fear2, modified by me. I call it fear3. I’ll post it up if anyone wants it.

Scripts:

screen_away.pl - I could not go without this one — especially because I use bitlbee for non-irc chat. screen_away allows me to go away automatically whenever I detach from my screen session. It does some other nifty stuff too, but this is all I’ve used it for.
nm.pl - Provides right aligned nicks and random nick colors.
adv_windowlist.pl - Another absolutely necessary one if you are going to use bitlbee. Provides a verbose window listing rather than the default window activity status.
bitlbee_*.pl - All the bitlbee scripts from irssi.org. They each provide a few things that make bitlbee a little more usable.

Without urgency hints, the irssi/bitlbee combo would be useless to me. Luckily I’ve taken care of this as outlined here.

I can say that this configuration is by far the most usable setup I’ve ever used for day to day chat. If you have any comments or suggestions, feel free to contact me.

Vim Tip: Comments

randy@rsontech.net (Randy Morris) — Thu, 12 Feb 2009 00:00:00

I’ve posted a follow up to this tip that details a quicker way to comment in vim by using a simple function. Check it out here.

From the “holy crap why didn’t I find this before” category…

When editing in vim, if you find you need to comment out a block of code, try the following:

Jump to the start of the line at the top or bottom of the block
Press Ctrl+v to enter Visual Block mode
Navigate to the end of the block. You’ll notice only the first column is highlighted (for the most part)
Press I to enter Insert mode before the first non-blank character on the line
Type whatever the comment syntax is for your language, eg. “//”
Press Esc to get back to Normal mode.

You can follow similar steps to uncomment the same block,Ctrl+v to highlight the comment characters followed by x or any deletion command to remove the comment.

SVN Diff and Vim

randy@rsontech.net (Randy Morris) — Mon, 22 Dec 2008 00:00:00

Now that I’m starting to really get used to using svn for all my config files and web dev work, I’ve noticed I use the command svn diff a lot. By default this outputs a unified diff to stdout if any differences are found. While this is good information to have, it’s a really sucky way to display it — especially when we have tools like sdiff and vimdiff at our exposure.

sdiff simply takes the two input files and prints them out side by side with changes noted as characters in between the files. While this is much much better than the standard output of svn diff, vimdiff is still a better alternative because of it’s syntax highlighting.

vimdiff (or vim -d if you so choose) opens up vim in diff mode. This mode by default is two vertical split screens with one file in each screen. As usual, vim does some highlighting magic to make the output pretty and more meaningful. It also has a few commands to make your life easier when merging two versions of the same file (read up on do, dp, :diffget and :diffput).

Anyway, on to the point. To set up svn to use vimdiff as it’s default output you’ve got to do a few things. First, you need to create a wrapper around vimdiff. This is because of the way svn calls the diff utility, as far as I know there is no way around it. My vimdiff wrapper is below.

~/bin/svnvimdiff
```
exec /usr/bin/vimdiff ${6} ${7}
```

After that, you need to do one of two things:

Create an alias that calls your vimdiff wrapper

alias svndiff='svn --diff-cmd=/home/[username]/bin/svnvimdiff diff'

Edit ~/.subversion/config to have the following lines

[helpers]
diff-cmd = /home/[username]/bin/svnvimdiff

Me vs. GNU Screen

randy@rsontech.net (Randy Morris) — Mon, 24 Nov 2008 00:00:00

I have beaten gnu screen into submission. For ages it has refused to let me start with screen number 1 instead of 0. Binding c to screen 1 was supposed to fix this. The cause? My fingers were too fast. Turns out that I need to also bind Ctrl+c. For your convenience, copy and paste the below into your ~/.screenrc if you have a similar problem.

bind c screen 1
bind ^c screen 1
bind 0 select 10

Handling Urgency Hints

randy@rsontech.net (Randy Morris) — Mon, 17 Nov 2008 00:00:00

Recently I found myself getting tired of Pidgin‘s multi-window interface and began searching for alternatives. Because I’m already on IRC all the time anyway, I decided to take a shot at Bitlbee. Bitlbee takes all the useful features of Pidgin and sticks them in a familiar IRC-ish interface. The only annoying part was that the message notification Pidgin gave me was gone — no more color changing tags/taskbar. Enter urgency hints.

I’d played with them before when hacking on dwm. In fact, I added this feature to my dwm because of Pidgin in the first place. My challenge now was to get irssi to pass the hint to gnu-screen, to pass the hint to urxvt over an ssh session, to pass it to my window manager. This was suprisingly easy. Three configs are involved: ~/.irssi/config, ~/.screenrc, and ~/.Xdefaults. Additions are shown below.

~/.irssi/config

settings = {
    "fe-common/core" = {
        beep_msg_level = "NOTICE MSGS HILIGHT";
        bell_beeps = "no";
    };
};

~/.screenrc
```
vbell off
bell_msg '^G'
```
~/.Xdefaults
```
urxvt*urgentOnBell:    true
```

With these three settings, I now get a nice notification when receiving a message in Bitlbee or irssi. This has a nice side effect too. Many cli apps can send a bell when they need your attention. Mutt, for instance, can now notify you about new mail.