On Jan 21, 7:43 am, "Edward K. Ream" <[email protected]> wrote:
> The title of this thread keeps being significant. The @test node provides a > way of experimenting with new code safely, without the need for a new branch. Good progress to report. Yesterday I added a long-overdue and fundamental improvement to the entire key-binding scheme: per-app and per-commander dicts. These dicts will allow Leo to compute which key bindings are actually in effect. Per-app dicts: - g.app.config.immutable_leo_settings_shortcuts_dict - g.app.config.immutable_my_leo_settings_shortcuts_dict As the names imply, Leo creates these dicts when reading @shortcuts nodes leoSettings.leo and myLeoSettings.leo. These dicts never change. They are class vars of the configClass class, so there is only one copy of each. **Important**: these dicts must be immutable because they are used (as described below) as the basis for the calculation of c.config.shortcutsDict for *every* commander. Per-commander dict: - c.config.shortcutsDict This is an ivar of the configClass class: there is a separate such dict for each commander (Leo outline). This ivar already exists: what will change is how it is inited and updated. Leo will create c.config.shortcutsDict by **updating** the initial settings in leoSettings.leo with the settings in myLeoSettings.leo, and finally by updating this intermediate result by the shortcuts in x.leo. Thus, we only need to understand how to update a shortcutsDict given an new set of shortcut settings. This is tricky, but the details can be handled by a single new method: merge_settings_dicts Testing this new method is the job of the @test node I am now writing. There are two, no three, no four, no five, important advantages of this approach: 1. config.getShortcut(commandName) will become trivial: it will simply return a (list of) shortcuts by calling self.shortcutsDict.get(commandName). 2. Dynamically creating a new binding will become much easier (and will actually work), because it will use the same merging logic used by merge_settings_dicts (possibly via a helper) 3. The @test node will allow me to specify exactly how merging settings is supposed to work. As I said earlier, this is tricky: spelling out the details will be an important addition to Leo's documentation. **Important**: the essence of this bug is that the present way of updating shortcuts does not work. Thus, the challenge is not to remain compatible with what Leo presently does, but rather to create a scheme that works as people would intuitively expect. Actually, few of Leo's users are likely to *have* real intuitions about what should happen, but the new update rules should be as unsurprising as possible. 4. The @test node allows me to test the new code *before* integrating the new code into Leo. Indeed, @test creates a test environment that is substantially *safer* than a separate bzr branch would be. 5. As far as Leo's core is concerned, the c.config API remains completely unchanged. Indeed, only init code in the configClass will change, along with the implementation of config.getShortcut. For this reason, there is no need to create a separate bzr branch. I expect to finish this bug in the next day or so, but that depends on making the update rules as simple as possible, but no simpler... 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.
