Part of the new direction for me will be building tools, including quite small tools. Examples:
While studying Blender, I revised the recursive import script so it merely created the @auto and @path nodes *without* doing the actual imports. The *next* time the .leo file opens Leo will actually do the imports. This turns out to be quicker and generally better. Some planned tools: 1. Revise the @auto import logic so it is less fussy. For example, it could use @tabwidth to convert tabs to blanks automatically, and only complain when doing so would create an invalid Python program. And it should just indent underindented comment lines without making a fuss. More generally, it should avoid warnings and report only errors. 2. Remove gnu copy-left notices from sets of files or nodes. Purely for study of course, but getting rid of this cruft would be quite useful. 3. gnu-indent followed by removing braces in .c files. Haha. Again, I find extra characters just so much sand in the mental wheels. 4. Static program analyzers to produce call trees. Some such already exist. With Blender, I feel kinda like the ca. 1980 days when I was disassembling code. Yes, the code is there, but it almost might as well be assembly language: about the only thing that is useful are the names of the classes and methods. 5. A debugging (or otherwise instrumented) build of Blender would be a good study tool. At present, I am stuck trying to get SCons to work... I'm going to look for more opportunities to build tools rather than slog through morasses of code. 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.
