ENB: Simplify configuration code?

[Edward K. Ream]

This Engineering Notebook post continues my previous ENB.  Here, I'll consider simplifying Leo's configuration code.

Background

Leo's configuration code is inherently complex because settings can come from (in priority order):

- The particular .leo file,

- myLeoSettings.leo,

- leoSettings.leo,

- hard-coded defaults.

c.config.getBool, c.config.getString, etc. are the interface to Leo's configuration code. In most respects this interface is excellent:

- The c.config methods hide all internal details.

- Unlike other python apps, Leo's classes need not be subclasses of configuration-related classes. Similarly, there is no need for configuration-related decorators.

So far, so good. However, many classes set ivars to "cache" configuration settings.  For example, the AtFile class contains this code:

self.checkPythonCodeOnWrite = c.config.getBool(
    'check-python-code-on-write', default=True)

There are several reasons why this assignment makes sense:

1. Checking the ivar is much faster than calling c.config.getBool.

2. More importantly, the assignment is an example of the DRY (Don't Repeat Yourself) principle. That is, it ensures that the default setting is always True.

All classes that cache settings contain a reloadSettings method that makes these assignments.  BTW, an alternate allowable spelling is reload_settings. Leo's reload-settings command calls all reloadSettings or reload_settings methods.

A simpler alternative?

One could imagine "banning" such cached settings ivars. Instead, the configuration machinery would cache the settings automatically. This scheme would work as follows:

- A settings cache would start empty.

- For each setting x, the first call c.config.get(x) method would compute the value, add an entry in the settings cache, and return the setting.

- Later calls to get the same setting would return the cached value.

- Leo's reload-settings command would just clear the settings cache.

This scheme would seem to eliminate all settings-related ivars throughout Leo. But there are problems:

1. Only the first call to the c.config.get methods would honor the "default" kwarg.

2. Several important settings have hard-coded "last-resort" defaults. It's not clear how to handle those settings.

Summary

We could speed up the c.config.get methods using caching. This scheme might eliminate the need for reloadSettings and reload_settings methods.

But the benefits of caching are small. The present configuration scheme is a decent balance of generality and speed.

Edward