This is the second part of a series on making the i3 window manager work the way I want. I left off last time with the goal of changing the way windows are placed as they are created, and I had a couple of pointers from the i3 hacking howto for where to start looking. This post covers how I've set up my test environment.
I've been using tiling window managers for the past couple of years. I started with awesome, then Notion (a fork of Ion; Ion is no longer maintained), and now I'm in the process of moving to i3. For those of you that aren't familiar with it, the screenshots all look the same. They all behave differently, though, and I guess you just have to find one that fits your mental model.
When you open a new window in most tiling window managers, your existing windows get rearranged or resized to make room for it. This is kind of one main idea, actually, and it works reasonably well when opening your second or third window. Beyond two or three, depending on the screen size and applications, it starts to suck.
Today's XKCD starts to answer: how much time should I spend making a routine task faster?
Inkscape is a good open-source drawing program for vector graphics. I'm currently using it to make a research poster, but unfortunately, Inkscape doesn't do bullets. This post discusses your options if you want to use bullets in your Inkscape drawing and introduces a simple Inkscape extension that makes this much easier.
To add color to your GDB prompt, place the following in your ~/.gdbinit file:
set prompt \033[0;33m(gdb)\033[0m\040
This makes it easier to find your place visually.
I store nearly all files of even moderate importance in Git (including this blog post). These are usually plain-text files, but sometimes it's necessary to put binary files under version control. Unfortunately, those are typically difficult to diff and merge, but I recently discovered some features of Git that make this less painful. This blog post focuses on SQLite database files, but at least some of it applies to other binary file types.
Dealing with a basic command-line prompt in a loop can be painful, so many programs, such as shells, interactive programming languages and debuggers, provide a more featureful prompt. For example, pressing the up and down arrows in a good prompt will flip through previously entered input lines. Programs will often make use of the GNU readline library for this functionality.
If you need to use a program that only has a basic prompt, you may be able to wrap it with the program rlwrap to get some more advanced features. From the man page:
rlwrap runs the specified command, intercepting user input in order to provide readline's line editing, persistent history and completion.
[...]
There are many options to add (programmable) completion, handle multi-line input, colour and re-write prompts. If you don't need them (and you probably don't), you can skip the rest of this manpage.
For example, I recently used rlwrap with jdb, the Java debugger, and Ikarus, a Scheme compiler.
Most people seem to have an opinion as to whether exceptions in C++ are slow or fast, but very few people have put any useful numbers out there. Here's a lower bound.