view on CentOS

When editing a file, it’s often handy to have a related file open for reference. For example, if I’m using a library function I might have the function definition open in a separate window. Or if I’m editing a configuration file on one server, I might want to see what the same configuration file looks like on a different server.

Vim has a read-only mode (vim -R) that is perfect for this purpose. From the vim man page:

Read-only mode. The ‘readonly’ option will be set. You can still edit the buffer, but will be prevented from accidently overwriting a file. If you do want to overwrite a file, add an exclamation mark to the Ex command, as in :w!. The -R option also implies the -n option.

The -n option stands for “no swap file” — since you will not be editing the file, there is no reason to create a swap file. This is a helpful because it allows you to open a file in read-only mode multiple times and vim will not complain.

Instead of typing vim -R, I typically invoke vim using the view command, which does the same thing:

Vim behaves differently, depending on the name of the command (the executable may still be the same file).

The “normal” way, everything is default.

Start in read-only mode. You will be protected from writing the files. Can also be done with the -R argument.

On Ubuntu, vi, vim, and view are all symlinks managed by the alternatives system. When the vim package is installed, all three commands point at the real binary, /usr/bin/vim.basic. Since all three commands invoke the same binary, the behavior is consistent across commands (except view invokes vim in read-only mode, as expected).

On CentOS, the situation is more complicated. The vim-minimal package provides /bin/vi and /bin/view, and the latter is just a symlink to the former. The vim-enhanced package provides /usr/bin/vim, then sets up a bash alias vi=vim in /etc/profile.d/ Unfortunately, there is no special treatment for the view command, so when you invoke vi or vim you get the enhanced vim, but when you invoke view you get the minimal vim. This can be annoying — for example, if you open a file using vi or vim you will get syntax highlighting, but if you open a file using view, you won’t.

Fortunately, the fix is fairly simple. Just add the following lines to your .bashrc:

if [ -x /usr/bin/vim ]; then
    alias view='vim -R'

This sets up an alias for the view command, so vi, vim, and view all invoke the same binary and the behavior is consistent across all three.

Womprat Colorscheme for Vim

My main “IDE” is vim in a terminal. For years, I used the default 16-color colorscheme, but recently I was inspired by a few blog posts about vim colorschemes and solarized in particular. I tried solarized for a bit, but I didn’t like that I had to change my entire terminal color scheme, and I didn’t like the blue background (just weird) and grey text (too low-contrast).

After trying out a few other colorschemes, I decided to create my own. I started out with David Liang’s wombat256mod, which is in turn based on wombat by Lars Nielsen. With a few hours of tweaking, I had something that (IMHO) looked pretty good on CoffeeScript, PHP, Scala, and diffs.

Continue reading

Lucene Scoring and elasticsearch’s _all Field

At work, I’ve been building a search application using elasticsearch. In my first post on the topic, I talked about indexing and analysis and ignored scoring entirely. Scoring is a very complex topic, but I’ll try to address some of the basics in this post. I’ll also cover a specific scoring-related issue with elasticsearch’s _all field.

Continue reading

Testing Lucene Analyzers with elasticsearch

Up until now, I’ve been using elasticsearch as a way to speed up filtering, not as a search engine for human use. Using elasticsearch for filtering is relatively easy — all the inputs are normalized strings, dates, or numbers, documents either match or they don’t, and the order in which documents are returned is specified by the client.

My latest project is to build a search application for human use. Building search for humans is a lot harder. Instead of filtering by known fields with specific values, you have to match free text. Instead of a structured query, you get one text box. The result the user was searching for should appear in the first few results, and because Google is ubiquitous, users expect the results to be just as good.

Continue reading

githublink.vim Plugin

I use Vim as my primary editor. I also use GitHub for a lot of my projects. On more than one occasion, I have found myself wanting to share the line under my Vim cursor with a collaborator in the form of a link. The manual process went something like this:

  • Go to in a browser
  • Navigate to the correct repository and branch
  • Drill down to the file I was working on
  • Find the line in the file and click on the line number
  • Copy the URL and paste it in the email or instant message

Wouldn’t it be nice if you could just hit a hotkey and have Vim figure out the URL for you? I thought so too, so I started hacking on Vim plugin to do exactly that.

To use the plugin, install it, then start editing a file that’s part of a GitHub-hosted repository. Press \ g (backslash, followed by g) to display the URL of the current line. You still have to copy and paste the URL, but everything else is done for you. Update: the plugin now copies the URL to the clipboard for you if pbcopy is available.

Some of the constructs for the plugin are borrowed from rubytest.vim, so thanks to janx for the rubytest plugin. This is my first foray into Vim script, so if there are better ways of doing things, please share!