Very nicely done! I would favor adapting prototype constructs into Leo. Any other way would mean that the new branches would be need to catch up to the rest of Leo as it evolves. Continual catch-up has been a problem for some other projects (more complicated than Leo, no doubt). It's possible that this wouldn't be a problem in practice, but it's hard to know at this point. This approach might be more likely to keep current plugins working, or working with minimal change.
On Friday, May 8, 2020 at 7:51:36 AM UTC-4, vitalije wrote: > > 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/ab3e6259-2663-49c9-b846-826f60365950%40googlegroups.com.
