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.
