I'd like to discuss what I think is most important, and why. The simplest, easiest, most general ideas are often the most important. Complexity definitely is not the same as importance. Let's look at some examples:
*Eliminating caching using super-fast reading* Vitalije's code essentially in-lined the entire read code. The result was almost exactly as fast as recreating the outline from the cache. So the file cache was no longer needed. Not only did this eliminate the horrid caching code, it eliminated a source of confusion for users. No more --no-cache option. This is the highlight of this year's work. *Caching only non-essential attributes* Leo caches marked and expanded bits, selected node and (maybe) topmost visible node. .leo files no longer contain these data, thereby reducing unnecessary diffs. An important simplification, well worth the work. *Better tree redrawing* The present Qt tree redrawing code is extremely slow when many nodes are visible. Happily, however, this does not happen often, especially when Leo is configured to automatically collapse nodes that are not in the subtree containing c.p. It would be possible to fix this bug without changing Leo's data model. Vitalije may have other ideas. We'll all evaluate the code when it becomes available. It would be good to fix this bug, but it isn't particularly urgent to do so. *New data model* The new data model may make tree redraw easier. The new data model is advertised to "stabilize" positions, though just how is not yet clear to me. This promises to simplify c.deletePositionsInList. I am *most *interested in whether the new data model will make it possible to represent huge outlines. *Refactoring code* Simplifications are always welcome, provided that they don't become mammoth projects. Simplifications aren't worth doing if they break lots of existing scripts or plugins. Leo's overall architecture is sound, whatever Leo's code level defects. There are more important issues than reducing localized code complexity. The LoadManager class contains Leo's init code. Whatever its complexity, it works. Simplifying it must retain *all* existing features, including compatibility with plugins. *New directions* This is the most important of all, but it's not completely separate from the above. Surely, eliminating file caching is a new direction for Leo. The recent discussion about supporting intermixed code and comments is a truly new direction. It's been on my mind for a long time, and variations have been frequently requested. More independent body widgets would also be welcome. The most important new directions of all involve new environments and new ways of collaborating with other tools. Joe Orr's work is one example. Better importers aren't so glamorous, but are still very important. I look forward to seeing what new importer framework Vitalije may create. 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.
