The revision 00bda92 <https://github.com/leo-editor/leo-editor/commit/00bda92c02f9d8edcfa9a6a6dec80d2e9e9a3661> contains improved test and a new command execute_script.
As Brian suggested in another thread I have changed the strategy for performing hypothesis tests. Now test chooses a sequence of commands excluding undo and redo commands. After each command if the outline has changed, test will check to see if the undo really reverts the effect of command and then redo it again. Executing 5000 tests now takes about a minute. No bug has been found yet :-). The new command `execute_script` has been added to the prototype. In order to keep things simple, this command uses only the body of the selected node as a script. It doesn't expand at-others and section references inside the body, nor it cleans other Leo's directives. If the script throws an exception the outline is reverted to its state before executing script. If the script terminates without exception all changes are recorded in the undo/redo history. This means that the scripts are undoable by default. This concludes my work on the prototype. *What next?* The main purpose of this prototype was to prove my claims about how Leo architecture should change. Which parts should be moved to View, which should be moved to Model and which should be moved to the Controller. The classes and methods that belong to VIew are Position, outline commands, chapter commands, hoist commands. But how to achieve that. Let's imagine an object containing all these methods. Each GUI can create an object with these methods. QtGUI will return an object much like the MyGUI from the prototype. The other GUIs can return an object constructed from the current implementation of these commands in Leo. That way those other GUIs won't have to change much. There is also another option. Instead of moving code from the prototype to Leo, code can be moved from Leo to the prototype. In that case Leo code can remain mostly unchanged. The prototype will evolve by copying (and adapting if necessary) the rest of Leo's features until it becomes a new complete Leo implementation. The third option is to forget about other GUIs for the time being. Refactor Leo's code freely in separate branch without limitations of keeping compatibility with other GUIs. Once this process is done, find a way to make other GUIs work again. Your comments please. Vitalije -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/25ea47d9-3b6f-45b3-988b-5e4376a62336%40googlegroups.com.
