There are unlimited levels of undo/redo at the moment, I'll have to add limitations as the next step (buffer override, performance issues)
The system uses a command queue system. The command queue is simply a big buffer (statically allocated 5 MB at the moment, I will change that to "Memory Mapped Files" later).
The command structure contains the size of the command, the type of the command and simply the arguments. Arguments can be anything, ints/doubles/string (from clipboard for example). Everything is just pushed into the queue. The queue """manager""" is just a huge switch statement, so I am not limited, I can push whatever I want and however I want into the queue. All I have to do is read the data in the same order.
The data is duplicated ("old"/"current") at startup/load: the old (loaded from file, for example) state is saved. The current data is updated at every command with the last command in the queue. The old data is unaffected. At Undo, all the commands except for the last one are executed on the old data. The command structure is not deleted from the queue so it's possible to Redo. If a new command is issued after Undoing, the commands after (and with) the undone command are deleted. (well, not actually deleted, but the end of queue pointer is adjusted, so they will be overwritten).
Later, when limiting the undo levels, the old data has to be updated with the first command in the queue, and the first command has to be deleted from the queue (only if the undo limit is reached, of course). It will be hard to implement because of the shitty design: global variables... I have to rewrite every editing functions....
This whole thing took about 10 hours to implement (I had to rewrite every functions for the command pattern)
My job as programmer
I overestimated my ability to do intellectual work in full time then intellectual work for another few hours a day. And my weekends will be "troublesome" (girl). I could do the job, but not this way, so I cancelled it in time.