On Wed, 8 Aug 2018 01:15:04 -0700 (PDT) "Edward K. Ream" <edream...@gmail.com> wrote:
> On Monday, August 6, 2018 at 9:34:56 PM UTC-5, Terry Brown wrote: > > There may be existing personal plugins that would break if plugins > were > > loaded after the outline was fully loaded, but then again it's > > possible to devise code that breaks in response to any change in > > Leo, it's impossible to avoid (particularly with no bright line > > between API and internals) - it's certainly happened to me often > > enough. > > True enough. > > I don't think we should say plugin loading time shouldn't be changed > to > > reduce complexity, although that doesn't mean making such a change > > is any kind or priority or that it even needs to happen. > > Why should we devs want to change to code that has worked for > decades. Where is the payoff? > > leoPlugins.py is relatively simple. It implicitly defines how Leo > loads plugins. Has anyone complained? Imo, this discussion is just > a distraction. We devs have (or should have) much better things to > do. > > If however there's a major complexity reduction gain to be had, I > don't > > really see a downside, *because* I can't think of a single outline > > manipulation that a plugin couldn't perform *after* the initial > > outline load. Given that plugins acting after initial load can > > change the outline in anyway they want, I can't see how there can > > be a manipulation that requires plugins to load early in the > > process. > > There is a huge downside... I see plugin load time and settings processing as separate issues, so not really sure how these two relate... > QQQ > EKR: How do you propose to pre-compile these settings? > > Vitalije: There are quite a lot different possibilities. Last year I > showed in a script how it is possible to take all settings from > c.config and put them in sqlite data base in memory and retrieve any > setting from this data base. > QQQ > > In the What's Important > <https://groups.google.com/forum/#!topic/leo-editor/XhhpF1K5tG4> > thread I said that eliminating caching was the highlight of this > year's work. > > Alas, saving settings (no matter where), is a form of caching! This > is a fatal flaw, because there is no guarantee that the *present* > settings files are in the cache. For example, the cache won't contain > leoSettings.leo when git pull changes it, and in other situations. > > Leo will *always* need the complex code needed to merge settings > from .leo files *outside *any cache. Unlike marked/expanded bits, > settings can't just be "blown away". > > In short, pre-computing settings is just wrong. Code simplicity *must > not *wag the dog. > > Edward Cheers -Terry -- 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.
