Monday, November 08, 2010

My Vim Configuration: Take 2

1 comment
More than a year ago I wrote about my story of switching (completely) to Vim as my primary editor. If you have worked in a Unix/Linux system seriously then you know why your editor (whatever it maybe) is a big deal. If you don't, let's just say as a SysAdmin and a budding DevOps type guy, my editor is a serious thing to me. So here's my Take Two.

Why?

If you are asking why I would want to write about a boring topic again, then this post of obviously not for you. This post is for anyone who's interested in using the mighty and great Vim editor and it's variations (Eg: vim, gvim, etc.) properly.

What has changed?

I had pushed my Vim configuration to a GitHub repo named gavim and had been using it for a while. And couple of people even forked the repo. Despite how proud I was about my editor configuration, ;) there were some obvious problems.

First, a few things were broken (Eg: proper snippet usage) and some plugins weren't working any-more (Eg: Fuzzy_Finder_Textmate) and I wasn't using some of the plugins and wanted to used some other plugins. Also importantly, I started using gvim (package name vim-X11 in Fedora) most of the time instead of just the terminal based vim. Edit: Since then I've moved back to using just vim mainly and gvim as a secondary. Apart from being leaner, it makes it possible to work in full-screen mode.

More than anything maintaining a Vim configuration was messy because you had to copy all the files from all the plugins into one hairy ball of a directory. I never liked that. Along came Tim Pope with Pathogen which changed how people can manage Vim configs.

So I sat down, threw away most of my old configuration files and started anew; Gavim2

Gavim2 (since renamed to Gavim, again)

Let's start with my .vimrc file. As usual I had copied over some default configuration stuff from Fedora's default system-wide vim configuration file. And started adding my preferences.

The option 'nocompatible' tells Vim that it doesn't have to try to be "exactly" like its father; the venerable vi. This is a must have if you are to enjoy the niceties Vim has. So instead of trying to be completely 'vi' compatible we can exploit additional features of 'vim'.

The 'bs' (settings for backspace) options allows me to backspace over a few things I like. For example "eol" will name vim allow me to use backspace to get to the previous line (above the line termination). The next two lines asked vim to keep a '.viminfo' file and to limit the command line history to 50 entries respectively.

The 'number' option tells vim to show line numbering. What I actually wanted to have was 'relativenumber' (commented-out line) which shows the line number relative to the line where the cursor is. This is handy when I'm deleting lines or yanking them. Unfortunately it's only available from vim version 7.3 (Fedora as of this writing uses a revision in 7.2 range). If I wanted to know the actual line number, I could always look at the status line at the bottom anyway. I hope Fedora updates to Vim 7.3 soon. Edit: It has. :) But I'm no longer using 'relativenumber' because it can be a little distracting.

'incsearch' allows to search incrementally while typing in the search pattern. This way I don't have to wait till I enter the full pattern to see results. 'modelines' value is set to "0" because I've read somewhere that it can be exploited as a security vulnerability. Although I can't remember exactly how it is done, I set the value to 0 because I'm not using modelines.

While 'ignorecase' disables the case-sensitivity in search patterns, 'smartcase' requires "ignorecase" and overrides it if the pattern contains any uppercase characters.

I've set the F2 key to toggle the "paste" option by setting it as the value for 'pastetoggle'. This is really useful if you want to copy something into what you are editing and temporarily turn-off auto-indentation.

The options 'wildmenu' and 'wildmode' works together to make the vim command line operate more like bash (i.e., shows the completion options when the tab key is pressed instead of traversing between options) and with a prettier menu mode. The latter invokes the first, if it's enabled.

Edit: I've also made vim use 2 spaces instead of a tab character. This is set with the options 'tabstop' (number of spaces for tab), 'shiftwidth' (number of spaces for an autoindent step), 'softtabstop' (number of spaces for tab when editing) and 'expandtab' (expand tabs into spaces). By using all 4 of these options I've made sure that what I write isn't messed up when viewed elsewhere.


I've also used used 'mouse' option to enable mouse use in plain vim. This makes the select with mouse behave more like gvim (Eg: do not select line numbers). For word and code completions sake I've also set 'ofu=syntaxcomplete#Complete'. Among other goodies, I've configured a keybinding (i.e.: ,?) to show the changes made since the last save.

The following things are explained in the comments.




Plugins & Bundles


What I've done with plugins is managing them with Tim Pope's pathogen plugin with the use of Git submodules.

As you might have already figured out my while Vim configuration is a Git repository, which makes managing things far easier and better. Since the use of pathogen makes plugins easier to manage separately and as bundles, I had all the plugins which had a git repository placed as git submodules. The rest are also added as bundles with a version number.

Here are the plugins I'm using.

1. pathogen
I have already explained s few things about pathogen. Seriously you need to consider using it if you are serious about maintaining your Vim configuration.


Pathogen had to load first. That is why I'm disabling filetype before pathogen and load it later, elsewhere.

2. nerdtree
This is a really cool file explorer as I've said before. I'm using it with the following config:


Which means I can use ",d" to toggle the tree pane and use "Enter" key to toggle collapsing the tree.

3. nerdcommenter
From the same guy behind nerdtree, this plugin makes commenting a breeze.

4. scratch
This plugin gives you a temporary buffer area which never gets saved. Nice to have something jotted  temporarily.


5. conque
This is a nice little plugin which gives you a terminal. It acts pretty similar to a standard bash. However you need to have Python ready in your system (which most common Linux do have usually).


6. ack

This plugin acts as a frontend to ack. Obviously you need to have ack in the system ready.

7. snipmate

This allows the use of some of TextMate snippets in Vim.

8. vcscommand
This is a frontend for many VCS tools including Git, hg, bzr, SVN, SVK, CVS

9. fugitive
This is a very col Git wrapper. If you don't want many VCSs and just need Git, this is the plugin you need.

9.1 gitv

gitv is a git commit history browser similar to gitk/gitg. It depends on fugitive.

10. bufexploreer

Is a simple buffer explorer plugin.

11. matchit

A pair matching plugin.

12. rails
A handy plugin if you are into Ruby on Rails web applications.

13. guicolorscheme and csapprox
This enables the use of GUI based Vim colorchemes in just the command line vim version.

CSApprox's more accurate and works most of the time unlike guicolorscheme. The purpose is the same. It enables the use of GUI based Vim colorchemes in just the command line vim version. 

14. latex
This very useful if you plan to use vim as a LaTeX editor/IDE. I've left the configuration in ".vimrc" but I usually install the plugin using package management tools.


I also have a few lines configured in ".gvimrc" file.

What these lines are configuring is how the gvim specific settings. For example I prefer to use Deja Vu Sans Mono font at 11pt as my font. Also I have set that the maximum number of characters per line is 80. After that I have disabled the toolbar, right scrollbar and left scrollbar (when the screen is split). Edit: Since then I've moved all these lines in to my "vimrc".


The Result


Click on the image to see the final outcome in actual size. I don't have a fixed colorscheme preference, but I've been using the colorscheme named "monokai" for a while. Edit: I still don't have a fixed preference. However I've added a load of 'colorschemes' to pick from.


If you want to see how things are organized, or grab my configuration files for Vim, you can get them from the GitHub repository. I've commented on my configuration with the file, just in case. Please note that you'll need git to set it up properly (i.e., it uses git submodules). For further instructions please see the README file.

I know this works straight away in latest Fedora, CentOS, RHEL, Ubuntu and Mint Linux systems. I haven't used it on any other systems, but if you want to try, I'm not stopping you.
Read More...

Sunday, November 07, 2010

Howto Install Docky on Fedora 14 (Laughlin)

9 comments
Edit: There's no need to compile Docky from source on F14 any more. The packages have landed on the official repos. If you still want to build from source, you are welcome to use this post. For everyone else, just fire a terminal and type:
$ su -c "yum install docky"
If you already had installed it from source, see the Step 0 below to uninstall it.

About five months ago I posted a blogpost named "Howto Install Docky on Fedora". Little did I know that people will be using my guide as much as they have being doing. A few things have changed since the original post which assumed that the Fedora version running is 13 (please see the comments on the original post) and also Fedora 14 has come out. Therefore, I though of writing a wee bit more up-to-date post eventhough any of this isn't anything remotely serious. This is just to avoid answering question on the original post, as much as for the sake of everyone. Also the official install guide from Docky wiki hasn't still been updated for Fedora 14. So here goes. :)


Installing Docky 2.0.7

If you got to see my earlier post or had try to run Docky on Fedora 13, then you know that gio-sharp software didn't have a packages version of Fedora. However Fedora 14 has a packaged gio-sharp, other required packages and related *-devel packages. It's the gio-sharp-devel, ndesk-dbus-devel and ndesk-dbus-glib-devel I'm actually looking for. Unfortunately packaging these made the situation worse if you plan to use the latest Docky source (E.g.: cloned bazaar repo).

Why? Because the latest version of Docky as of this writing requires higher versions of (some of) the above mentioned software. So what we are going to do is, just sacrifice running the latest snapshot and run the latest stable release (which is 2.0.7 as of this writing).


0. Remove any version of related packages you have installed from source (i.e. without using a package managing tool). If you followed my original post, this means you'll first need to uninstall Docky (do to the build directory and run su -c 'make uninstall' ) and gio-sharp package. If you have any package installed using the package management system you'll need to uninstall it the same way (i.e., # yum remove your-pacakge).

Also, needs to removed is the environment variables set on behalf of Docky. If you followed the original post, those would be PKG_CONFIG_PATH and MONO_PATH. If you had set them manually before, unset them now (i.e., remove or comment out the necessary lines in the file you used).

If you don't do these two things, you are highly likely to run into trouble. If you didn't have any prior Docky installation in your system, just skip to step 1.

1. Install the dependencies by running the following command. You'll need root password when prompted.
su -c 'yum install mono-devel bzr bazaar automake intltool gcc GConf2-devel gtk-sharp2-devel gnome-desktop-sharp-devel gnome-keyring-sharp-devel mono-addins-devel dbus-sharp-devel gtk+extra-devel notify-sharp-devel gio-sharp-devel ndesk-dbus-devel ndesk-dbus-glib-devel'

Or, you can do the same with using "sudo" instead of "su -c" (and minus the quotes as well) if you have your system configured to use sudo.


2. Download Docky version 2.0.7 from launchpad.


3. Extract the downloaded source archive.


4. Open a terminal in the extracted directory (or just 'cd' into it).


5. Run:
./configure

If everything is Ok, it'll show the state, or else it'll show some error message. Provided you follow the instructions correctly, you should be fine.

This step will generate the data for the compiler to use such as directory locations among other things. So after you finish this step, don't try to change the directory locations and names.


6. Run:
make

This will do the compiling and building for you. If everything went well, you are ready to install.


7. Run:
su -c 'make install'
or
sudo make install
based on your preference.


That's it. If everything worked for you this far, you can try launching Docky using 'docky' command or create a shortcut (which should already be created in Applications --> Accessories menu if you are using a GNOME desktop).



Living on the Edge (Installing Docky from latest snapshots)


I'm not going to give specific steps here because this is a moving target. But I'll point you towards the right direction.

A. Make sure that you have uninstalled and removed all the remnants from earlier Docky installations. Also see Step 0 in the previous section.

B. Install the dependencies (see Step 1 of the previous section) minus dbus-sharp-devel and gio-sharp-devel.

To be honest I haven't tried this method myself beyond this. And it might not be possible at all to install the latest Docky without completely ruining your Mono environment or worse. But if you are feeling up to it go ahead. Just don't pretend I didn't warned you. ;)

C. Grab the latest (or the necessary) versions of the dbus-sharp and gio-sharp packages from source, build and install them.

It's much better to find SRPMS from Koji or elsewhere and rebuild the RPMs for the latest version, then install using package management tools. Explaining this is well beyond the scope of this post. If you already know how to do that, I have no idea why you are reading this post. :)

D. Hopefully this should be enough to run configure and make steps (See also Step 5 & 6). If this is not the case and the configure/make is complaining about version mismatches, you'll need to remove the package in question (using package management tools) and build them from source.

This is a slippery slope, which is why I didn't try it in the first place. So be warned, YMMV, very much.

E. Once you successfully compiled the system you can run it as usual. Just make sure whenever you update, to read the documentation and update (i.e., uninstall and install the latest) the dependencies.

It maybe not perilous as it sounds. But if you are not up to taking the risks, I'd suggest you follow the first method (installing the stable release) and be happy.


Honestly I'm a little amazed about the number of hits (and feedback) my original post ("Howto Install Docky on Fedora") is getting. I know these are things that's quite easy to figure out if you know your way around a Linux system. But for a new user simple things can make a big difference.
Read More...