I have no idea if this is relevant, but in looking over @settings recently, I remembered the issue with plugins wherein it was difficult (impossible?) to de-activate a plugin appearing in leoConfig/leoSettings.leo.@enabled-plugins
Was that ever resolved? If not maybe instead of bare names in @enabled-plugins, Leo could use vim = enabled (or =True) stickynotes = enabled mod_scripting = enabled ... allowing for downstream to say vim = disabled (or =False) or some such. Thanks, Kent On Tue, Feb 14, 2012 at 11:11 AM, Edward K. Ream <[email protected]> wrote: > This post will be of interest only to those with a deep interest in > Leo's implementation. Feel free to ignore. > > At present, Leo's configuration code is a wretched mess. You can see > several aspects of this mess by looking at g.app.config.get: > > 1. This g.app.config.get searches several "weird and wonderful" > dictionaries, accessed by name or by list, to get the value of a > single setting. > > 2. You would think that the code would be in c.config.get, but no, > it's not: The configSettings class in leoCommands.py simply calls > g.app.gui.config to do all the work. > > In another thread, I summarized the planned new process as follows: > > QQQ > Rather than the baroque code in g.app.config.getX, each c.config > [object] will contain two "finalized" > settings dicts, one for shortcuts and one for all other settings. To > get a setting, the c.config.getX methods will simply look up the > setting in the appropriate dictionary. > QQQ > > Here are the details: > > 1. To compute the "finalized" version of the *shortcuts* dict, the > init code will start with the hard-coded settings, then merge the > settings from leoSettings.leo and myLeoSettings.leo (if they exist), > and then merge the settings from the local file being loaded. Merging > dicts is tricky, but merge_settings_dicts handles the details. > > 2. We compute the "finalized" version of the *settings* dict in a > similar way, but merging dicts is much easier: we can simply use > d.extend(d2) > > 3. Initing setting will be a two-stage process. The first stage > merges the hard-coded settings and the settings from leoSettings.leo > and myLeoSettings.leo. This first stage only happens once. > > The second stage will happen for each loaded .leo file. The second > stage merges the result of the first stage with the settings from the > file being loaded. > > **Important**: In this second stage, leoSettings.leo and > myLeoSettings.leo will be treated just the same as any other .leo file > if they happen to appear in the load list. In particular, this means > that settings from myLeoSettings.leo will apply to leoSettings.leo if > leoSettings.leo is in the list of loaded files! > > 4. At present, the config_iter code computes knows the "source" of > each setting because it knows which of the various weird and wonderful > settings dictionaries actually contain the effective value of the > setting. We must preserve this source information for the print- > settings command, so the process of merging information must *add* the > source information to the finalized dictionary entries. > > 5. Given the per-commander finalized setting information, retrieving > that information becomes much easier. c.config.get will simply return > something like c.config.finalized_d.get(setting_name). > > 6. Overriding settings will happen much as it does at present, but the > changes will be to c.config.finalized_d instead of wherever it happens > now. > > 7. The g.app.config class will do nothing but create settings > initially; the c.config class will handle almost all aspects of > getting and overriding settings. > > 8. During development, the g.new_config switch will control whether > the old or new config code is in effect. I'll probably set the > new_config switch only after the new_load code is nearly complete. > > 9. **Important**: The new scheme will eliminate the wretched dict that > presently associates commanders with settings. Bugs accessing this > dict are the reason for bug 568452: local @settings ignored if file > opened from command line with absolute path. Although standard > settings files *will* be read twice if they appear in the load list, > the only remembered information will be the finalized settings dicts. > Thus, we can eliminate c.hash rather than fix it. > > 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. > -- 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.
