This thread will discuss the workflow I use to develop Leo. The intention is to help present and potential developers use Leo effectively. This thread will be pre-writing for a section of the users guide.
This is a continuation of the thread: http://groups.google.com/group/leo-editor/browse_thread/thread/4494324d21bd0bde/adf6d565c90e175c Overview ======= Here is the big picture: * Develop in an outline containing all of Leo's source files. Close this outline rarely: this keeps the code I am using stable while I'm hacking the code. * Test in a *separate* .leo file, say test.leo. In fact, I often test in a private file, ekr.leo, so that test.leo doesn't get continually updated on bzr with trivial changes. These two points are covered in a bit more detail in the FAQ: http://webpages.charter.net/edreamleo/FAQ.html#how-can-i-use-leo-to-develop-leo-itself Additional tips: A. Avoid using the mouse whenever possible. For example, use alt-tab to switch between windows. B. Always develop Leo in a console. This allows me to see the output of g.trace. Speaking of g.trace, I hardly ever use 'print' because g.trace prints the name of the function or method in which it appears. The typical pattern for enabling traces is: trace = True and not g.unitTesting if trace: g.trace(whatever) This pattern is especially useful when a method contains multiple calls to g.trace. C. I use scripts to open particular Leo files. These are batch files on Windows, and aliases on Linux, but invoking them is the same on either platform: all: opens all my main development files using the qt-tabs gui: leoPy.leo, leoGuiPlugins.leo, leoPlugins.leo, leoSettings.leo, myLeoSettings.leo and LeoDocs.leo. t: opens test.leo. e: opens ekr.leo. I use this file for private testing. d: opens LeoDocs.leo. s: opens LeoPy.leo. plugins: opens leoPlugins.leo. gui: opens leoGui.leo. u: opens unitTest.leo. These run Leo with Python 3.x. There are similar scripts, ending in 2, that run Leo with Python 2.x. For example, u2 opens unitTest.leo with Python 2.x. Similarly, the tk prefix uses the Tk gui: utk opens unitTest.leo with --gui=tk (and Python 2.x since the tk gui only works with Python 2.x) Thus, to run a test, I alt-tab to an available console window, then type 'e' or 't' or 'e2' or 't2'. D. Use clones to focus attention on the task at hand. For more details, see: http://webpages.charter.net/edreamleo/intro.html#clones-views The projects section in leoPy.leo contains many examples of using clones to create view nodes. I typically delete the clones in the views shortly before a release. E. For thousand of example of my programming style, see leoPy.leo and leoGuiPlugins.leo. That's about all for code-level tips. Here are some administrative tips: A. Use postings as pre-writing for documentation. I don't mind blabbing on and on about Leo because all my posts become pre-writing for Leo's documentation. I simply copy posts to nodes in the "documentation to-do" section. At release time, I edit these nodes and put them in Leo's main documentation or the release notes. This posting is an example. B. Never rely on memory. A project like this contains thousands and thousands of details. Everything eventually goes into a Leo node somewhere. If it doesn't it surely *will* be forgotten. C. Do easy items first. This keeps to-do lists short, which in turn helps keep energy high. That's about it. Let me know if you would like clarification or amplification of any of this. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
