On Wed, Oct 3, 2012 at 10:25 AM, F.S. <[email protected]> wrote: > For large nodes the speedup is quite significant. Could this feature be > turned on as a directive like @killcolor.
Excellent idea. @cachecolor and @nocachecolor will allow node-by-node control. We can then eliminate the g.cache_color_info without affecting Leo's default operation. > Another observation: With caching turned on, if I @killcolor a node, the sub > nodes that were visited already maintain their cached colors while the > unvisited nodes don't have color. Interesting interaction of features here. Hmm. You could call this a bug. I'll look into it. Edward P.S. I am not very happy with the actual details of the color data is cashed. Today, I was just interested in creating the infrastructure needed to save and restore data. Now that the infrastructure mostly works, it's time to see if I can improve the original prototype. At present, the save/restore code assumes that some underlying C++ data will disappear when the QTextDocument changes as the result of switching nodes. Indeed, earlier drafts of the code took a hard Python crash--presumably for just this reason. My present mental model is that the QTextLayout is freed when switching nodes. That's why write_colorizer_cache laboriously (and incompletely) copies data from layout.additionalFormats(). Naturally, what I really would like to do is to hold these additionalFormat's in memory, but I'm not sure whether that's possible. Perhaps the C++ sources will provide some useful clues. EKR -- 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.
