The new approach thus keeps a complete copy of the .cmd file in memory, divided in blocks. Each block holds lines that should be edited together, like the full configuration for one monster, the settings for one plane, etc. I'm almost done. All that's left to fix is spacing in generated lines.
I quite liked how the former version of LEDS had some "controller" class (WelcomeWindow) that provided an empty vector to LevelModel so that it'd fill it with the objects the view (MonstersManager) would use. Unfortunately, in the new version, the relationship between code blocks and in-editor structures (like the Monster instances) got more complex, and a flat vector no longer works well. The new Block class offers the ability for any part of the code to crawl through the sequence of Block instances that were generated while parsing the level's cmd file. Unfortunately, this dependency between LevelModel and MonstersManager has turned implicit while it was nicely explicit before.
There's just one design decision I wish I could validate with a magic crystal ball. Any line on a GameScript that starts with a 'g' is now packed into a GobBlock unless that GobBlock refuses it (if so, a new GobBlock is created). That means the gob%.focus had to be changed into focus=gob%, for instance. Not exactly what I'd recommend in any serious project, but the syntax of GameScript is fairly simple and should not receive further significant extensions.