OMG: Leo's reload-settings machinery can be greatly simplified!

[Edward K. Ream]

PR #4582 adds an entry in a table in the c.reloadConfigurable method. This table is evil: it must somehow stay in sync with all classes in Leo's codebase.

I created #4583 to address the ugliness and went to bed :-)

But before I went to sleep, I realized that none of Leo's existing reload-settings machinery is necessary. Leo's two configuration classes can do all the work!

See  #4583 for the details. Hurray!

Edward

[Edward K. Ream]

On Thursday, April 2, 2026 at 8:37:05 AM UTC-5 Edward K. Ream wrote:

> [None] of Leo's existing reload-settings machinery is necessary...See  #4583 for the details.

Alas not. The existing per-class reloadSettings/reload_settings methods always update their per-class ivars.

But g.app.config.getX and c.config.getX can't possibly tell their respective config classes how to update those ivars later.

I have just closed  #4583 as a misguided idea. Boo hoo.

Edward

[jkn]

I do appreciate the way you post your 'dead ends' here, as well as triumphs etc ;-)

    J^n

[Edward K. Ream]

On Thu, Apr 2, 2026 at 1:16 PM jkn <jkn...@nicorp.co.uk> wrote:

I do appreciate the way you post your 'dead ends' here, as well as triumphs etc ;-)

You're welcome. Only fools never change their mind or admit their mistakes.

Edward

[Edward K. Ream]

On third thought, there may be a way.  The getX methods could take a new required arg that specifies the ivar to be updated.

Yes, this change could break existing scripts and plugins that Leo knows nothing about. But the getX methods could detect this missing arg (without crashing :-) and print a message, once per plugin or script. This message would alert the Leonista that their plugin or script needs updating, and that the reload-settings command won't work on the given plugin or script.

Naturally, I'll need to provide a conversion script to add the new arg.

Summary

I'm not sure that this scheme is a good idea. What do you all think?

Edward

[Edward K. Ream]

On Saturday, April 11, 2026 at 3:39:55 AM UTC-5 Edward K. Ream wrote:

> On third thought, there may be a way.

Nope. Further investigations reveal that trying to "improve" the code would just make Leo's codebase uglier.

In short, #4583 seems doomed. I have closed it yet again.

Edward

[Thomas Passin]

Thank goodness it's closed.  Please do not even consider breaking Leo's API without a compelling reason. Even then please keep the old version and introduce the new one in parallel. Some people depend on their scripts, like me, and even apart from that there are bound to be edge cases in the code base just waiting to bite.