On Sat, Aug 24, 2019 at 8:54 AM vitalije <[email protected]> wrote:
IMHO the real problem is the way Leo handles settings at the moment. I have > suggested several times in the past to change this. > I do not at all agree with this proposal. First, I'll make specific comments, line by line. Later, I'll discuss what I think Leo's future project leaders would be better off thinking about. The way I see it is this. Leo handles settings using the very same > functionality that is used to handle its primary data - outlines. > Having setting be outlines has many advantages, including the various @button scripts in leoSettings.leo. > One might think it was a clever idea that saved some coding. > It's not just a clever idea. The effect on coding is, from a design point of view, irrelevant. The question we must ask, first, is whether such settings benefit users. But if we honestly and without prejudices, look at the result of this idea, > we can see that it caused numerous complications in several other parts of > Leo. Initialization code is an excellent example. > That may be true, but there is no way I would allow major changes in settings now. Doing so would unnecessary inconvenience Leo's users. But there is much more examples. One of the most extreme I can remember is > that there is a call to c.endEditing very early before any gui element has > any chance of being created. > Imo, c.endEditing does something reasonable, regardless of the behind-the-scenes complications. By the way this call is spread throughout the code base, contaminating and > entangling all Leo's modules. I am not very convinced that it is still > necessary because there had been many changes since it was introduced. It > would be good to look how to eliminate the need for this call. But this > should go to another topic. > I agree. This belongs a separate discussion. However, as I note below, Leo's devs have much more important things to worry about. Let's continue with the way Leo handles settings. Let's first split this > idea in two parts: > > 1. editing settings as an ordinary outline > 2. loading settings from the outline > > The two parts are not necessarily bound to one another. They can be > changed separately without too much trouble. While I am not very interested > in changing the first, the second one IMHO should be changed in order to > simplify other parts of Leo, and I am pretty sure the simplifications would > be significant. > I am definitely *not* going to change the user's view of settings. We might consider adding to settings outlines, but I have no interest in doing so. If we ask users both newbies and seasoned are they satisfied with the way > Leo handles settings, I guess we would find many more unsatisfied users > than the satisfied ones. > Maybe. I don't know any way to do a valid survey. I remember loosing many hours on more than one occasion while trying to > solve some settings issue. I am afraid of touching any settings because of > these bad memories. > This section <http://leoeditor.com/customizing.html#search-order-for-settings-files> in Leo's docs says: QQQ This search order offers almost too much flexibility. This can be confusing, even for power users. It’s important to choose the “simplest configuration scheme that could possibly work”. Something like: - Use a single leoSettings.leo file for installation-wide defaults. - Use a single myLeoSettings.leo files for personal defaults. - Use local settings sparingly. QQQ Imo, this scheme should work for most users. Leo now has several tools that allow users to see where settings are coming from. Many things are impossible or prohibited because of this. There is no way > user can load and unload plugins without restart. Python is dynamic > language and there should be no problem to allow this. > The problems with unloading plugins do not involve settings. Plugins can modify many aspects of Leo. Undoing such general actions can be difficult to impossible. LeoPluginsController.unloadOnePlugin is supposed to unload a plugin. How well it works is another matter. The issues are similar to Python's imp.reload. > In almost all other editors plugins are downloaded from the internet, > installed and switched on and off with the single click. Leo users can't > possibly dream about such a feature mainly because of the way Leo handles > its settings. > Again, I disagree. > Switching the theme is impossible without restart. > Maybe, but again Leo's settings really are not the issue. > *What can we do about it?* > > After editing settings in the myLeoSettings.leo or any other settings > outline, user should invoke a command to save settings. This command can be > executed automatically on each save. This command would read settings from > the outline and build settings dict as it is now done during the startup > code. > Leo pretty much works this way now. The result set of settings can be stored in g.app.db for the next run. > During the startup settings can be retrieved from the g.app.db in one line. > This would require the least changes in Leo's code. > This introduces a *secondary* caching scheme, in addition to Leo's present primary settings code. There is *absolutely no way* this scheme can simplify Leo's code. Caching creates the potential for nearly limitless confusion. The real value of your excellent fast @file read code was that it completely eliminated file caching. Why you think that caching settings would be more benign? > However there might be even a better scheme. > I'm not going to comment on the organization of the proposed caching scheme. Caching settings is a truly terrible idea. Now, adjusting any setting would be as easy as executing a simple SQL > command. Calling afterwards c.reloadSettings should apply new setting value > immediately without any trouble. > At present, adjusting any setting is a matter of changing the setting, and then reloading all settings. *Summary* > > IMHO your idea of having global settings is not bad at all. > I strenuously disagree. Leo has no real need for global settings, and it would be foolish to complicate Leo's settings machinery further. The only thing I would change is not keeping it in an .ini file, but > instead in the sqlite3 database, so we get parsing, querying, persistence > for free. > This idea conflicts with the way Leo handles settings now. To resolve the > conflict, you should change the way Leo handles settings now and it would > simplify many parts of Leo's code base. > No way am I going to do this. That's the end of my specific comments. *The bigger picture* Any future project leader must consider two somewhat contradictory goals. They would naturally want to add important new capabilities to Leo. Otoh, they must maintain stability if at all possible. Principle 1: *First, do no harm*. Devs must be aware of the dangers of any significant change to Leo's code base. Principle 2: *Put Leo's users first.* Never needlessly inconvenience Leo's users. Never change any aspect of Leo without the strongest reasons. Respect their investments in settings, scripts, and learning. Principle 3: *Don't bother criticizing Leo's code base.* Leo's code base isn't perfect, but it is *not* an obstacle to innovation. By far the safest approach is to minimize changes. You don't have to debug or document code that hasn't changed. Some recent examples: - The discovery of how to init pyzo in a sytematic manner. - This week's discovery of how to add global docks with virtually no changes to Leo's code. These discoveries where worth almost any amount of work, because they showed how to use existing code bases elegantly. Corollary: Study and experiment with existing code a long time before contemplating major changes. Corollary: Don't waste time criticizing code bases. The console gui required virtually no changes, either to Leo's code base or to the npyscreen code. Similarly, thinking about changing pyzo, black or pylint would be a distraction. Principle 4: *Confusion and bugs waste more time than anything else.* When users (or devs) are confused, the effects lasts for minutes, hours, days, months or years. Coding efficiencies typically save from microseconds to seconds. Corollary: Never introduce needless caching. *Summary* My biggest concern is that future devs will have an insufficient sense of danger. Leo's future project managers must never inconvenience or confuse existing users. We haven't finished exploring the Leonine world. Let's not distract ourselves with small complaints about Leo's code base. Imo, messing with Leo's settings is a complete waste of time. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS2CrmqDtw1qYbnfbo83bKhoyZMUNsmhHqxaUScsEbfe0Q%40mail.gmail.com.
