Parallel Programming 1

I've recently been thinking about how to write a text editor. I've written one or two in my time, so why write another? Well, mostly as a programming exercise and because I can.

In thinking about how to do this in a new and novel way and most importantly: efficient way, I came up against some mental hurdles.

In any programming project there is a translation that has to happen between what's in the head and what comes out on the page. Somehow the model in your head has to be coded into a model inside a computer. This process is hard.

So how to write a text editor from scratch? Inside my head, I have a document, a mouse and keyboard and type away. What's so hard about that? Well the problem is one of representation. Let's break it down.

First the document has to be modelled. Well, its a bunch of text contained in a set of lines. This translates to an Array in code. Good. The size of the array gives you the number of lines and each element of the array contains a line of text. Well, maybe.
The problem is that of wrapping, ideally we want our text to continue on to the next line when we type, if we reach the edge of the screen (or window). Ok, so we can use a big string of text to represent our entire document instead, and wrap to our heart's content. Good. Well maybe not.

The problem with a big string representation of text is that for a given position in the text, you don't know what line on the screen you're on. And you need this information in order to position the insertion point (cursor) correctly. It gets worse, characters on a modern system all have different widths, an i is skinnier than an o, so if we have a line of text in an array, we don't even know where to put the cursor horizontally without taking all those widths into account. Ok, so we write functions to work all these things out for us.

Ok, so we plumb for the big string representation, keep a note of the character position in this string to represent the insertion point and run a bunch of functions when we need to work out screen positions etc. The problem with this, is that it's inefficient. Any time we change any bit of text, we need to recalculate the whole lot to display it on the screen.

So how can the efficiency be improved? The answer is to have a good model in the first place and to only re-calculate the absolute minimum in response to a keystroke for example. This is hard, primarily because we have to take a lot of cases into consideration, and re-calculate differently based on each case.

The answer will be in my next blog.