Bug of the moment 2007-07-19

One of my beliefs is that software functionality should not be arbitrarily limited; generally, this laziness will only cause inconvenience to users when their needs exceed the limits of the design. Sometimes, though, software limit levels prove high enough to be twistedly, morbidly amusing.

Many text editors allow a document window to be split into panes so that the user can view multiple parts of the same document. BBEdit 7 permits only two panes, split horizontally. Macintosh Programmer’s Workshop 3.5 however, I discovered, allows up to seven panes split horizontally.

Then I discovered that it also has horizontal splitting. Moreover, horizontal and vertical splitting are independent of each other:

A crazed division of an IDE window into 18 randomly-sized panes

I am not sure whether this is 2007’s You Cannot be Serious award winner, or whether it should be lauded for the nearly unbounded freedom that it offers the developer. There are bugs, of course, when you come to disassemble the panes:

Disassebling the grid of panes leaves large areas of the window not drawn in correctly or at all

(The first image also has a redraw problem if you look closely.)

Logic puzzle

Here is where it gets strange. It seems to be a carefully disguised logic puzzle created by Apple. Panes have a minimum width and height, but there are also limits set on how many you can create. My first attempt to create a complete grid was going very well: I had built most of the 126 possible panes (14 × 9) when I was informed about a PowerPC unmapped memory exception at 3D169AE4 (now my site will draw hits in from everyone searching Google for “3D169AE4”, putting me naturally at the number 1 spot).

Undeterred, I tried again:

The same 108 panes, but with each one scrolled to show a single view of the document, like a TV wall

This attempt scored me 108 panes. You can see that I have clearly not succeeded, and you will soon see why. My next attempt was to alternate my direction of subdivision, but this is the point where I was unable to create any more panes:

If I release the mouse here, the Mac beeps at me and the pane won’t create.

I took another approach. Here is one place that I cannot create a pane:

Here, vertical subdivision is disallowed,

but horizontal subdivision is allowed, whereupon vertical subdivision is now permitted within the three horizontal panes I formed:

Here, however, vertical subdivision is not allowed, unlike the panes below:

Here is the completed grid:

An alternate grid layout giving me only 92 panes this time

This time, I scored only 92 cells. Each intersection can only be resized one way, according to how it was originally created, so the program will be having fun trying to keep track of the whole situation (until it goes down in flames anyway). Analysis of the acceptance patterns may well yield the correct sequence of steps to create a complete grid, although I cannot be sure that such a pattern exists. Curse you, Mr PowerPC unmapped memory exception at 3D169AE4.

Incidentally, Meagan, this was not the entry I had in mind for you – that was yesterday’s – but if you ever needed to see my Insanity Credentials, here they are. Enjoy.

The C++ code itself – from my computer science student days – is even worse, with such delights as #included C++ files and lines like result = openLog ((argc == 3) ? (char *) &argv[2] : (char *) &"./Navajo log");

Posted 19th July 2007 – Comments and questions?