Status report: settings branch

[Edward K. Ream]

This branch contains work on the "show-settings-outline" command.  This command now works. More work is needed to ensure it is works accurately ;-)

What you will see

This command creates a fully functional outline, which may save if you like. 

It demonstrates a proposed way of showing settings.  The top level nodes are:

- Active settings for <name of the local file> # The .leo file, from which the command was executed.

- <name of local file>

- <name of theme file, if any>

- myLeoSettings.leo

- leoSettings.leo

The children of these nodes (except the first node) contain copies of all the active nodes of the @settings tree for each outline.  Active nodes are either:

- settings nodes (including children of @data and @outline-data nodes) or

- organizer nodes whose descendants contain settings nodes.

@ignore trees and all other organizer nodes are cleaned away.

In other words, these trees follow the organization of the corresponding @settings tree, with unnecessary nodes not shown.

Note: settings nodes that are not "active" have headlines starting with "INACTIVE".  I think they actually show potentially serious problems, but I can't be sure yet.

To do

1. The present code finds settings nodes in a dubious, probably buggy, manner.

Instead, the settings in effect for any local .leo file are exactly those settings present in c.config.settingsDict.  These settings will be "allocated" to the various files using the new c.config.getSource method, which should guarantee that the allocation is exactly that used by Leo's present show-settings command.

2. Per Vitalije's suggestion, there should be a command that writes all newly-changed settings nodes to myLeoSettings.leo.

Summary

The present command illustrates a proposed organization for the various outlines.  The data shown may be incorrect in some cases.

Edward

[Edward K. Ream]

On Monday, September 2, 2019 at 7:05:14 AM UTC-5, Edward K. Ream wrote:

To do

1. The present code finds settings nodes in a dubious, probably buggy, manner.

Instead, the settings in effect for any local .leo file are exactly those settings present in c.config.settingsDict.  These settings will be "allocated" to the various files using the new c.config.getSource method, which should guarantee that the allocation is exactly that used by Leo's present show-settings command.

Done. Progress has been rapid.  However, my wrist is bothering me, so I may have to take a break.

There is a bug in show-settings, which has carried over to the show-settings-outline command.  show-settings should handle settings in theme files separately.  Everything should work as expected once this is fixed.  I'll then go about simplifying the code that recognizes the various kinds of settings nodes.

Edward

[Edward K. Ream]

On Monday, September 2, 2019 at 7:05:14 AM UTC-5, Edward K. Ream wrote:

This branch contains work on the "show-settings-outline" command.  This command now works. More work is needed to ensure it is works accurately ;-)

Work progress satisfactorily.  It can be difficult to know what's happening, because the c.config.settingsDict contains so many entries.  And the g.GeneralSetting class sucks, as #1316 asserts.  So (big sigh) I think I have to do #1316 next, in a new branch, based on devel.

To illustrate the problem, yesterday I spent several hours gnashing my teeth, wondering why c.config.getSource didn't work, when LM.computeBindingLetter does work.  Well, the answer was that the contents of c.config.settingsDict was different in the two cases.  I had forgotten my own trick of using a deep copy of that dict to ensure that show-settings-outline was accurate.  Sheesh.

Yes, I could let #1316 slide, but if we are ever going to simplify settings, #1316 seems like a regret-free start to doing so.

Edward

[Edward K. Ream]

On Tuesday, September 3, 2019 at 7:56:24 AM UTC-5, Edward K. Ream wrote:

>...if we are ever going to simplify settings, #1316 seems like a regret-free start to doing so.

Could there actually be regrets?  Could this work possibly be wasted?

I don't see how.  However we init settings, surely each setting must be represented as an object of some class.

But just now I can't explain why g.GeneralSetting should have a dict, or be a dict.  The simplest thing that could possibly work would seem to be a class with a fixed set of ivars.  I'll investigate.

Edward

[Edward K. Ream]

On Tuesday, September 3, 2019 at 8:13:17 AM UTC-5, Edward K. Ream wrote:

But just now I can't explain why g.GeneralSetting should have a dict, or be a dict.  The simplest thing that could possibly work would seem to be a class with a fixed set of ivars.  I'll investigate.

My bad. The g.GeneralSetting class is as described above. It need not change.

Instead, #1316 now asserts that it is the TypedDict and TypedDictOfLists classes that should be dicts.  Which makes much more sense ;-)

Edward