Recently I got my hands on newly published “Hacking Vim 7.2″ which is a refreshed edition of the most up-to-date book about Vim on the market.

This review is mostly comparison-based. If you’re interested in more detailed analysis of book take a look at my content review, published some time ago.

First of all, if you’re wondering how much the book has changed - well, not much. This is still a good piece of writing, with some minor tweaks. I think that lack of any introduction to this new version (compared to previous) in the book itself, clearly shows that it should be treated as retargeted content (with focus on Vim 7.2 users), not as new edition¹. Below you can find differences I’ve spotted and how these affect general perception of this title.

Content added

Throughout the whole book there are multiple small additions, like (beginning with Chapter 1.) list of topics to be discussed at the beginning of the chapter or common terminology paragraph. Also some infos that are widely used in other IT texts showed up, for example “Who this book is for?” and “Getting Vim”. Titles were added to examples (making them visible in Table of Contents), however not to all of them.

Biggest new parts of text are two new subchapters. The one discussing how to handle snippets with snipMate script - especially useful for people creating new content on large scale. The second one showing that it’s possible to use Vim as microblogging client, making TwitVim script a starting point.

Content modified

There are also some modifications in book, of which the most important one is bigger index, extend by almost 100% percent (but bare in mind, that previously it was only 3 pages long) - this will be probably much appreciated by readers.

Formatting changes and reorganization tweaks took place, too. “Vim Scripting” chapter was split into two separate “Basic Vim Scripting” and “Extended Vim Scripting”, although I haven’t spotted any additions here. The screenshots are wider now making them more readable. Lists (of parameters for example) were replaced by tables which created a more reference-like layout.

Also, in some places language was simplified, to make statements more clear and concise.

Content removed

Some elements in book were removed, too. For example, in first chapter unnecessary graphic with vi clones was deleted. Fortunately, I haven’t found such removals disturbing and affecting overall feeling about the book - except for one component.

Due to retargeting book to address only Vim 7.2, it was decided to remove all info about versions in which each feature was introduction (a.k.a “since when given tips are applicable”). In my opinion such info was pretty much unique, as there’s no other place when you can follow Vim history so easily. However, this is not a crucial part of the book and, as such, should not affect your preception of text in a big way.

Summary

Overally, the book hasn’t changed that much - it is still a really good piece of writing, although some may consider it too shallow. Be advised: it is not a huge cookbook, but if you’re seeking some advancement in editing skills and don’t know where to start, this book is a great starting point with very good collection of tips and tricks. From time to time a look into this book as reference or when I seek inspiration in reduction my code editing time, so it is not a one-time read.

Below you can find small mindmap that summarizes this review.

Thanks to Packt Publishing for letting me review this new book.

A lot of code has been written since last report, while refactoring and creating new plugins. Details follow.

The goal of this part was to close elements related to GUI extending and, generally, plugin management. Some clean-ups have been made also to prepare code for events handling part.

First of all, a few changes have been made to PluginManager class - even if plugin is deactivated it is an instance object, not class object. This gave opportunity to add init method, where devs can put some base operations that does not depend on plugin current activation state (speeds up plugin activation).

The biggest change is connected with plugins configuration. It is now fully-featured, based on shelve and UserDict modules and transparent to plugin developer. Config files are not plain-text, as this is Python pickling, but you can easily save dicts, list, tuples. In future, this will be probably rewritten to some custom class and integrated with Gajim’s main config facility.

I’ve written new plugin: Banner Tweaks (based on patch by pb), that allows people to easily achieve compact banner in chat windows (difference can be seen on screenshots). Old plugin Message Length Notifier has configuration window now, so it’s fully usable (see screenshots). I’ve also added JIDs filtering feature to it (for which JabberIDs notification should be used). To show roster extending possibility I’ve written small plugin, Roster Buttons that adds quick access buttons to it - one of them shows/hides offline contacts (idea taken from Psi).

Aparat from that, extension points cleanup mechanism has been added, so dead references are kept no more. In addition, needed modifications have been done to Gajim core and plugins.

What’s keeping me busy

I feel obliged to inform community about things that have influence on my time dedication to GSoC project. First of all, I’m very close to finishing my master’s thesis - delays were maybe mostly because I started (again) reviewing state-of-art of information retrieval and what impact can it have on my project. Great reading of a lot articles published by Springer and IEEE.

Second of all, and it this is more important, I gained the title of Certified Project Management Associate, after passing IPMA lvl D exam. Looking at list of certicate holders in Poland. I’ve realized that I’m one of the youngest persons on that list (AFAIR second or third in row).

Open-Source feelings

At the end, I just wanted to write that Yvesf wrote LaTeX Plugin using API in my branch (haven’t played with it much so far checked it out and it works nicely). Great feeling to know that someone else starts to use your code Probably this is one of open-source rewards…

It seems that another week during GSoC has passed. This one was mostly GUI-related.

I’ve wanted to let people experiment with plug-in system ASAP. That is why I’ve created Plugins management window ([9762]), where they can (de)activate all detected plug-ins and read information about them.

I’ve committed another plug-in example (after Message Length Notifier) - Acronyms Expander ([9777]). Now, users have more elements to play with and I can test how Plugins window deals with multiple real-life elements.

Plugins management window

Current version of Plugins window, with it’s basic functionality, is a good base for further development. There are two tabs: ‘Installed’ and ‘Available’ (visible on screenshot).

First one shows plug-ins detected locally (installed). Here you can easily (de)activate them by toggling tick in table view on the left. This seems like an obvious way to do that

‘Uninstall’ and ‘Configure’ buttons are mocks. The first one will simply remove plug-in’s files locally. The second one will invoke plug-in configuration dialog.

‘Available’ tab will show plug-ins available on-line for download. Maybe using Capuchin.

Suggestions on this one are really appreciated, as this is what final user will mainly see.

Plugins window is accessible through Edit/Plugins menu item in Gajim’s roster (just below Preferences) - visible on screenshot.

GUI is built using Glade 3 with some parts, like gtk.TreeModel handling (used to store plug-ins list), in Python code. This approach is consistent with current Gajim code.

Acronyms Expander plugin

Message Length Notifier plug-in is useful but it’s not much to play with. So, I’ve implemented another plug-in for users to test - it’s a well-know (to many) Acronyms Expander.

It works “live”, so the substitution takes places while typing message. Below are hardcoded expansions of acronyms. This will be, of course, configurable, once I implement settings saving for plug-ins.

Currently the only invoker of expansion is ' ' (space).

To implement this plug-in for both, chat and group chat, windows I’ve added new GUI extension point. It’s called 'chat_control_base' and is situated in ChatControlBase class.

Acronyms Expander plug-in works well (without conflicts) with Message Length Notifier.

Unsolved cases and thoughts on upcoming challenges

Plug-in’s config

Main issue to solve now is configuration saving for plug-ins. We could pickle data to plain-text file, but it’s hard to read and modify - not human-readable, really. However, it’s fast and very general - plug-in could save anything.

Another approach would be to extend ConfigParser and implement cases of list (read from str) and maybe other types. Here, format is easy to read/modify outside Gajim (eg .using text editor). Unfortunately, AFAIK ConfigParser (as mentioned) does not support lists storage by default. So, we would have to use eval() function, and we want to avoid that (due to security reasons).

We could also use ConfigObj, but it would be another dependency - not sure if it’s worth that.

Apart from problem called ‘how’ there’s also a question of ‘where’. Probably, we’ll make separate config file for each plug-in. Sounds really reasonable, because one plug-in won’t mess up configuration file of another one.

PluginManager refactoring

I’ve, recently, realized that we might want to configure plug-in when it’s deactivated. In such case, I have to reorganize PluginManager a little bit.

Current version: keep class object for plug-in itself and instance object for activated plug-in.

Future version: keep instance object and call initialize(), destroy() methods when plug-in is activated/deactivated - these would have to implemented by each plug-in.

Automatic handlers (un)registration will be left untouched.

I could leave code as it is. But dealing with configuration at class object level would be a ‘programming abuse’ IMHO.

Extension points clean-up

GUI extension point clean-up is still unsolved. Extensions points called from objects that are not referenced by Gajim core anymore, should be removed. Currently, they are not deleted. Objects are still somewhere in memory, although not used, because they are on GUI extension points list in PluginManager).

Further tasks:

• start playing with network/xmpp events. Walk around code and think of events hierarchy and implementation.
• work on events generated by Gajim itself (like 'AccountConnected') (proposed by xbright). We would have to determine which events do we need and give plug-ins possibility to handle them. Signals are already generated for Gajim’s remote control - this looks like a good starting point.

More than a week passed since GSoC kick-off meeting took place. So it’s time to summarize a little bit.

For those that don’t like reading longer posts - in short: Gajim (de)activates plug-ins while running and first plug-in works pretty nice. Detailed report follows.

At the beginning…

…there was creation of new branch in Gajim’s Subversion repository, dedicated to plug-in system ([9703]). Thanks to this, I’m independent from trunk and what is going on there (aka I-won’t-break-trunk). Main problem here is that merging branches in Subversion might be pretty painful.

But still (nevertheless I’ve been warned by Kev), I’ve decided to use it instead of DVCS like Git or Mercurial. Mostly because of two things:

• plug-in system won’t make many changes to current Gajim core (so it might not be so hard to merge branches at the end) and Subversion is already there, working.
• I bought Wing IDE Professional about two weeks ago and I wanted to have support for VCS within IDE. Unfortunately, WingIDE supports only SVN, CVS na Perforce.

Wing IDE - Python helper for project new-comers

After some time, it occurred that the second statement (in the list above) is not necessarily a good argument. This is because, SVN support Wing IDE is not the best I’ve ever seen. To be honest - it’s pretty basic compared to Netbeans or Eclipse. I ended up using console to interact with SVN - it’s more handy.

However, Wing IDE is a great tool to explore Python code. It’s source code analysis is probably the best one available on the market. Whole IDE is pretty fast, has nice debugging facility and integration with PyLint. Automatic indentation checks are pretty handy to keep code consistent with Gajim’s core. In fact, there’s a small clean-up commit in trunk that is the effect of using this feature in Wing IDE: [9704]

Some things that WingIDE badly lacks (apart from DVCS support):

• movable tabs
• all-at-once highlighting when searching
• show-all-usages of function/class/variable (there’s only ‘go to definition’). Someone even posted feature request for this today on wingide-users mailing list.

So much for the IDE I use during GSoC. Going back to project itself.

Few words about trials of Getting Things Done

First of all, I’ve decided to use tracer bullets approach for my GSoC project. I think three things are important for me in this method:

• I meet problems that I wouldn’t imagine (in finite time), keeping all the ideas and code only in my gray matter. There are lots of things that you can miss or forget. However, Paper-And-Pencil(tm) application might slightly reduce this problem.
• I can get feedback from people early, because some code begins to work pretty fast. Of course it’s not perfect. Many elements need polishing or modifications, but still - the code works.
• Unfortunately I have other projects that I have to work on in parallel, so thinking about project only and no coding would probably end-up in freaking out (being overwhelmed by amount of work to be done)

This way, I move forward. Sometimes making bigger steps, sometime smaller, but permanently towards building plug-in system for Gajim.

What I’ve noticed, is that using this approach I always know what to do next. Not only at general level of project by also at code level.

I’m lucky because I write my GSoC project in Python which simply makes prototyping fun.

I admit I feel inspired by “Getting Things Done” that I got from XSF (stpeter, Kev: Thanks, once again). I especially liked paragraphs about procrastination

Initial commits and testing

After creating own branch and doing some coding I’ve commited a few files ([9737]). Later, some improvements were made ([9745], [9754]). Resulting code has:

• new package called plugins where I keep code related to plug-ins system
• PluginManager class where all plug-in management related actions are placed
• GajimPlugin class that is supposed to be the base of of all plug-ins. All subclasses of it are treated as plug-ins.
• helpers module that includes: Singleton class, customized logger and functions decorator that logs when function is enter and when left
• test_pluginmanager.py file that holds tests (or I should say: one test) of PluginManager class
• additional variable common.gajim.PLUGINS_DIRS where directories to seek plugins are hardcoded. Maybe later we’ll decide to move it to config file.
• first call of GUI extension point in ChatControl class
• first plugin that makes use of this extension point was implemented. It’s called Length Notifier. I mentioned it in previous post when in was in a form of monkey patch. It highlights message entry field when given length of text in exceeded. Pretty useful with microblogging bots, eg. Twitter.

Notes on PluginManager: directories are scanned for ‘*.py’ files in which they search for GajimPlugin subclasses; plugins themvelves are held as class objects in list (maybe I’ll change it to set), while activated plugins are held as instance objects in separate (also) list;

Notes on Singleton: this implementation calls __init__ only once in contradiction to version that is in “Python Cookbook”; I’ve been warned by Kev that singletons might be deadly. So I’ll have to decide , whether I really want (need?) only one instance of PluginManager, before releasing plug-in system to the World.

Notes on LengthNotifierPlugin: some data (i.e. handler IDs) needs to be stored per object, this is done by assigning dictonary to object as new attribute; this is a simple solution and Python allows such approach, so why don’t do it this way? Plug-in developer, of course, can modify object in any way he wants. One of such modifications is saving data to object.

Notes on testing: I’ve copied some initial code from bct’s tests on sessions. Unfortunately, we have to make some dummy objects, to get tests run. Without that there are exception like NameError or ImportError - it’s mostly related to configuration. This init-hacking part will be probably extracted to separate module¹ as it seems, that all tests will need it.

API docs and Epydoc

Probably I could write even more descriptions of code here, but a better solution is to keep all this information closer to code - yes, in code documentation

I started discussion about documentation standards last week, because I wanted to create docs in format consistent with the rest of Gajim’s code.

The result of discussion can be seen here: http://gajim.org/apidocs/ .

The decision was made to use reStructuredText syntax for documenting and Epydoc for API docs generation. It was chosen because it’s Python dedicated and permanently under development with new features in each release.

The use of reStructeredText seems to be a reasonable one, because, as mentioned by Torsten Bronger, there’s a PEP on using it in Python code documentation (this makes it, more less, a standard). Apart from that, reST syntax in Epydoc has consolidated lists which makes docstrings more readable, IMHO.

Targets for (not so) near future

Things that I plan to do next:

• short-term:
  • make erasing GUI extension points possible (currently: references stay on list in PluginManager even if Gajim doesn’t have interest in them anymore)
  • decide on how to store plug-ins config - first shot here would be to generate API for plug-in developers, implement some local saving/loading with pickle and later integrate with current mechanism that Gajim use for configuration. All of this is because present Config class is pretty restrictive. I’ve already had discussion about it with Jim++.
• long(er)-term:
  • GUI for plug-ins management - to get more feedback from users. If there’s GUI more people may feel encouraged to test the branch.
  • scan for packages and zipped code, not only for module files
  • add GUI extension point for roster and for one of context menus in it - this will cover most of the GUI that potential plug-in developers are interested in
  • discuss about handling events, filtering them - generally, the network-related part of GSoC

To see more TODO and BUGS info checkout docstrings in plugin-system branch.

Ending note: I don’t know whether such (more less) detailed reports make sense. It took me some time to write it. I’ve spotted that, especially, creating links consumed a lot of time. Maybe I’ll have to look for abbreviations plug-in for Wordpress. Another solution would be to put only summary here and point to detailed descriptions in docstrings or changesets.

Any suggestions appreciated - have you found all this info useful?

Almost 4 days ago Google announced list of 1125 fortunate students that will be developing open-source projects this summer and get paid for it. Luckily, I’m within this group - here’s my quick report and initial thoughts.

I’ll probably end up with “initial report and quick thoughts”. Nevertheless, if you don’t know what Google Summer of Code is, check out official program website or Wikipedia. In short, one may compare it to normal software development internship, except two differences: you work on real open-source projects and coding is done remotely from where you reside currently (probably home, in most cases). This has a few consequences.

First of all, your coding time is flexible. You can code in the morning, you can code after midnight. For US students this may not be such a big advantage, because they start summer holidays when GSoC starts (end of May). In Europe however, students end academic semester at least a month later. Yes, yes - you have to code during exam sessions, which is why flexible working time is so important.

Second of all, you get rich contact with leaders of open-source communities. If you have Linux box you probably use software from at least one third of them, if you’re a software developer, then from more than a half. This year there are 175 organizations involved in program (although I’ve counted 177 on official list - duplicates?). Generally they divide into two categories: umbrella orgs, like Python Software Foundation or XMPP Standards Foundation, and single-project orgs, like Wordpress and BZFlag.

All of this is done to reduce bus factor of valuable open-source projects. However, life shows¹ that only a small percentage of participants stays in communities after GSoC, so probably it’s a subject for improvement.

GSoC evolution

In 2008, GSoC has it’s 4th edition. And it is getting bigger each year. In 2005 there were 416 accepted proposals, this year there are 1125. Basically at the end of this year, if everything goes as planned, Google will have given out around 15,000,000$ to students and orgs overall (during 4 years). I’ve prepared two charts to visualize this - one with stats about accepted proposals and the other one showing Google’s financial engagement. These should be floating somewhere around here. Generally “The Company” spends 5000$ per proposal (4500$ for student and 500$ for mentoring org), if it’s fully successful (AFAIK success rate of GSoC is around 90-95%). Apart from this they’ve probably spent lots of money on administrative part.

In comparison: GHOC is much smaller and Android Challange is a promotion event with $10 million for awards. I’m wondering when there will be similar contest for recently released Google App Engine…

Plug-in system for Gajim - my GSoC project

So much for GSoC itself. This section is devoted to project I’m going to code.

First of all a proof that I’ve been really chosen - I’m listed at last position on the list of projects accepted by XMPP Standards Foundation. I also attach small screenshot on how this looks in student’s panel, which may be considered a semi-proof

Basically to get a feeling what it is all about you can read abstract of my proposal. If you want to get more details, jump into my notes on Gajim’s wiki². These are the effect of discussions with Gajim developer’s and my thoughts on architecture. I think we’ve been able to point out each element of system that we should keep in mind while desgining and coding. During my internship at IBM Polska I’ve played a little bit with Sametime Connect SDK. This let me start concept work right ahead (about one month before proposals submit deadline).

Generally the target is to get basic plug-ins API working (hopefully, also stable) at the end summer. It should let developers hook into Gajim’s data flow and modify GUI. What we keep in mind all the time are possible real-life plug-ins that we should be able to implement based on this API. In example: XMPP over BOSH, LaTeX formula renderer, server-side message archiving or OTR support for Gajim.

What’s done so far

One of Project Management principles is that if you want to measure your progress precisely you have to know where you started exactly. So here it goes.

During preparation to plug-in system coding I’ve embedded IPython shell in Gajim and it works pretty well (although there are a few issues to be solved ). It’s already in Gajim’s svn trunk and really accelerates learning source code structure. Asterix created DBUS interface for toggling it’s visibility, so it’s really usable out-of-the-box now. I’ve tuned my local version a little bit (see attached screenshot).

I’ve been able to duck punch GUI in a few places in a similar way it will be extended using plug-in system. Some proof-of-concept modifications were made to roster (static GUI) and roster context menus (dynamically generated GUI).

As a more useful proof-of-concept I’ve written “live” acronyms expander that works pretty nicely, so I already have code to put within plug-in API. I’ve also made maximum length notifier³ which I find pretty useful when using Twitter ⁴. I’ve made some trips around source code too, learning a few things from Asterix and Steve-e.

In short, plans for nearest future: determine places (exact lines) where we could add GUI extension points, design and write some basic API and basic plug-in manager to load modifications on start-up. After getting this running, I’ll get back to events handling system and work there on fundamentals to make this element extensible⁵.

We’ll probably update schedule on-line to make it reasonable. I think the key to success here is to keep in touch with mentor as much as possible.

XSF GSoC 2008 Community

Speaking of which, I think that I won’t have any mentor-student communication problems. The forementioned Asterix is Yann Leboulanger - my project mentor. He’s a kind of person that’s really opened for community and newcomers, and as Gajim’s lead developer keeps development on track. I also regularly talk with Steve-e about plug-in system and source code structure. And there’s lots of other helpful community members - you can check it out by joining Gajim conference room.

Apart from Gajim society, I’m also part of XSF GSoC 2008 community - it counts 6 students (3xPoland, Czech Republic, Russia, Turkey) and 5 mentors (2xUSA, Belgium, France, UK). I’ve put them all on Google Map (shown at the bottom) to visualize what are our geographical relations.

We have our own secret mailing-list and even more secret conference room Generally the leaders here are Peter Saint-Andre and Kevin Smith. The latter one came up with a great idea to keep us inspired all the time during GSoC - each of us is going to get two classic books: “Getting things done” and “The Pragmatic Programmer”. We’ll also probably have a chance to put a few bullets in each others heads, in the name of “community bonding”, during MP FPP shooter session (title to be chosen). I’ll probably suck rock pretty badly but maybe gislan or senu will be able to defend our national pride

Seems likes it’s the end of initial report. I’ll post updates on work progress when something significant happens.

IMPORTANT NOTE: If you have any comments on plug-in system in Gajim, especially plug-in ideas and thoughts on architecture - mail me, Jabber me or leave a comment below. Any discussion’s appreciated.

Some time ago I committed a short, introductory lecture about Vim at popular LUMD series. This is the review of the book that starts exactly where that tutorial ends, leading to a fascinating world of Vim’s advanced features.

I’ve started with pointing out my tutorial not because it is unique, but because it is not - as many on the web. “Hacking Vim” by Kim Schulz, the book that is reviewed here, is a set of well selected hacks that help to deceive the time flow. A kind of set that rarely can be found printed.

What are you talking about, anyway?

Vim is well know for a few things from which two can be considered most popular: quitting issues after first running¹ and interesting policies of efficient text editing. If you haven’t heard of the second one check out classical 7 habits of effective text editing by reading original text version or by watching video from lecture by Bram Moolenaar himself.

It is hard to edit text without Vim after getting deep into it (or even just making one step towards it). For example: I’m editing this post in gVim using It’s All Text! Firefox extension. Believe it or not but you can steal time with Vim and “HV” book it the easiest way to achieve it in my opinion.

So, what do I get?

“HM” equals almost 200 well-written pages filled with good advices how to speed-up work with Vim. The adventure starts with short introduction that includes origin of the editor.

I want pink background and huge fonts!

Second chapter begins core text of the book. Here you can find how to easily personalize highlights in text or add menus/toolbars to your GUI. It is a good place to point out that a lot of the information placed in book can be found in manual (especially from chapter 2) but it is included in a more descriptive way, which makes it pleasure to learn new tips.

Vim manual is a great source of information but it is the ultimate source which makes it hard to learn from. Personally, I’ve read almost whole Vim6+ manual. Even though I tried most of elements mentioned there it was hard to place them in your every-day text editing. “HV” represents some small subset of manual + lots of author’s experience included in examples and explanatory notes, which is a much better way to get editing habits.

What I noticed is that I treat this book, as some kind o diary/blog (probably this common for mono-authored cookbooks) with some ideas I can confront with my every-day habits. This make this book sometime more thrilling than many narrative texts :]

Getting back to personalizing Vim author describes some version 7+ features that I have personally never used seem to be pretty useful (or at least nice-to-know): modifying tabs and tool tips.

Let my fingers rest

Chapters “Better Navigation” and “Production Boosters” seem to the center of a book, especially the second one which is packed with the newest Vim7+ features.

First mentioned chapter should be a part of every-day editing of any Vim user. Mechanisms like marks or searching in multiple files really help your fingers rest. What I really liked about this part is that it includes tips about efficient searching the help system. This makes readers more comfortable in a Vim world after they finish reading the book.

As I already mention “Production Boosters” are a great selection of tips that make your Vim the tool more time-saving than most of the current IDE’s editors². If you haven’t heard about omni-completion, undo-branching or templates in Vim this is the chapter you should start reading with, as, in my opinion, these can be the biggest time hackers in book. Although it really depends on what you use Vim for.

If you still use handmade indentations every time, there’s a deep-in description of auto-indentation systems in Vim in chapter called “Advanced Formatting”. There also some solution for people that need formatting in plain text, i.e. headlines or lists. Personally I rarely need such functionality so it’s hard for me to judge how useful these tips are.

Let the real hacking begin!

For those that have noticed bad habits in their text editing, but haven’t found solution for them in the book, author included “Vim Scripting” chapter. After reading it one will be able to create, with full understanding, syntax-color schemes, Vim scripting and pack them to be installed by others. I must admit that this the best introduction to Vim scripting I’ve ever read. Mostly because it keeps constant level of complexity which makes it easily readable for everyone. This chapter takes up almost one third of a book - semi-proof that it is a comprehensive source of information at some level. If your priority is to understand codes presented in Vim Scripts collection you should start reading with this chapter.

I don’t need that book - I’m a geeky, nerdy Vim h4ck3r !!!

If you consider yourself a real Vim hacker maybe it is pointless for you to read this book. I personally think of myself as an average Vim user with few years experience who sometimes makes bad-habits-detection sessions and try to get rid of slow-downs. Keeping that in mind look at the pie chart below:

I’ve marked every tip with it’s own header with one of the three categories:

• tips I know and use [37 marked]
• tips I read about somewhere but used only once or never used [22 marked]
• tips I have not heard of or heard very little [40 marked]

The results say one thing at least - if you’re a typical Vim user you will find at least one tip that you haven’t heard of Maybe it will be the one from life-changing category…

Diamond without a scratch?!

It’s always hard to find any defects of a book that one loves from the beginning. I’ve read every page of “Hacking Vim” and even though it was difficult to point about any disadvantages³.

In fact there are only two things to correct: minor character errors - mainly in codes (I’ve found only a few) and used commands/settings index. This would be very helpful to get even better overview of what was mentioned in a book, but this time from scripting side. This is the only thing that made me a little bit uncomfortable during reading (just felt I miss something). However, Kim Schulz made added something more pleasant - Appendixes. With them I’ve cleaned up my configuration files and recalled that Vim can do everything - starting with games and ending with mail clients.

Some time ago I purchased two other books also originally published by Packt (republished by Helion in Polish language). I must admit that all three suits well to the meaning of modern IT book. Although, I didn’t really liked Ajax and PHP⁴ I was fascinated with UML in Action and loved “Hacking Vim” — all three books are well-though, creative and published with a really clean layout which makes it easier to read and find information. I point this out because it’s not so obvious to other publishers. Sometimes books are really chaotic and you should spend your money for something else, like roller coaster or a dinner with your girlfriend — more valuable and for sure more thrilling.

Summarizing: I admire Packt for publishing this book, as it is not a very popular subject⁵, and thank them for making this book of a really high quality. I really had fun reading this and checking how it contradicts to my habits in something what every computer user does - text editing⁶. If you’re an average Vim user - read this book, if not for knowledge then for inspiration in time hacking with Vim.

At the end I would like to thank Packt Publishing for letting me review this book and Kim Schulz for writing it.