Skip to main content


Showing posts from 2015

Persistent 'undo' in ViM

I love  ViM . It's universality, simplicity and keyboard-only-controllability appeals to me tremendously. I hear Emacs is better, but I can't be bothered to learn it. ViM suits me just fine. However, there's one ViM shortcoming that has annoyed me endlessly. It's inability to maintain edit history across buffer switches. To put it simply, it maintains the edit history that allows undo's and redo's only for the current buffer being worked on. The moment you switch to another buffer, the history is cleaned up and a blank one is given to the new file. Well, it turns out that ViM has the capability to preserve edit history for each file across buffer switches. Like many other features of the editor, you just gotta turn it on from the rc file. Here's how you do it set undofile set undodir=$HOME/.vim/undo set undolevels=1000 set undoreload=10000 With this in your rc file, ViM creates a temporary file for each file being edited in the folder pointed to by 

Practices to reduce memory leaks in C++

One of the fundamental differences between C++ and the more modern and if I dare say popular programming languages such as Java and C#, is the lack of a garbage collector in C++. Often this is used as an example to portray how C++ has not kept up with the times and how code written with the language is a potential minefield for memory leaks. While the debate about the merits of one language over the other continues (and in all possibility would continue for many more years), there are a few steps one can take, as a programmer, that can pretty much minimize, if not eliminate, the chances of a memory leak. I would like to list some of the techniques that I have employed over the years and have worked for me pretty well. Use RAII Use objects to abstract concepts Use std::auto_ptr Turn on memory tagging Use std::vector<> to allocate memory Declare base class destructor as virtual Use RAII Use RAII (Resoure Acquisition Is Initialization) programming paradigm: Per

Django Localization Issues and Solutions

Django has excellent support for building a multi language multi culture application. However, there are a few interesting bits about its implementation of the internationalization feature that can prove to be minor annoyances in truly localizing yoru web based application. This post aims to discusses these issues and highlights the solutions for them. It matters where you run 'makemessages' command from The core command that prepares the application for localization,  makemessages  can be launched from two locations and depending on where it's launched it behaves slightly differently. The command can be launched from project root folder or from an application folder. If started from the project root, it attempts to extract all the localizable strings from all installed apps and put them in the  *.po  file. However, if started from an application subfolder, it only extracts the strings from that application's files. The key issue here is that  makemessages  wo