This post will be me thinking out loud. Feel free to ignore. *Background*
On my fastest machine, all unit tests run in 34 seconds when using the curses gui, compared with 59 seconds when using the Qt gui. I spend a lot of time running unit tests, and it would be worthwhile to increase their speed. Also, redrawing the screen with qt makes unit tests fragile: they can fail if focus changes while tests are running. All guis represent Leo's *visual elements* (log, body, and tree frames, minibuffer, dialogs, etc.). Various unit tests depend on the properties of those visual elements (and especially Leo's underlying data structures) in various not-too-clear ways. An important aim of this project is to clarify these hidden relationships. *The idea* Unit tests might run more quickly than even the curses gui by running unit tests with a *string gui*, a gui that represents all visual elements by strings only (along with ints representing insert point and selection range). In that case, redrawing would be a do-nothing. Visual elements would be represented by subclasses of the leoFrame.StringTextWrapper class, a simple and thoroughly tested class. *New and deprecated commands* *If* this new scheme can be made to work, there would be three new commands: run-all-unit-tests-with-string-gui run-marked-unit-tests-with-string-gui run-selected-unit-tests-with-string-gui The run-*-unit-tests-locally commands must be retains so we can test the real qt (or curses) gui when the gui code changes. However, I am thinking of deprecating the run-*-unit-tests-externally commands. I hardly ever use them, and I have forgotten why I thought they ever were useful. Perhaps they run faster :-) *Summary* This is a highly experimental project. Just disabling redraws causes lots of tests to fail. It remains to be seen whether using a string gui will compromise important unit tests. But regardless of outcome, there will be gains resulting from deep study of the code: 1. Recent revs have removed all code associated with the _editPosition ivar and editPosition and setEditPosition methods of various (subclasses) of the LeoFrame class. Such do-nothing ivars and methods are pure cruft, and they can be very confusing. 2. Study of the code and failing unit tests, will reveal subtle interactions between the unit tests, the gui redraw code and Leo's core. I'll be documenting what I find. Edward -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.