On Tue, Aug 27, 2019 at 2:52 AM vitalije <[email protected]> wrote:
I can see that your idea of using Leo's reading outline code twice both for
> reading outlines and for reading settings is too dear to you and you are
> not going to let it go.
>
Ah. I didn't understand that this was the main idea. It wasn't clear to
me from reading your initial post.
You have pointed me to the page from the documentation that warns users
> about possible confusion when setting their preferences. I assure you that
> on more than one occasion I have spent hours trying to fix problem with my
> settings that was caused just by updating Leo, and I have always had only
> one myLeoSettings.leo.
>
If, as you assert, the "user will notice nothing", then how can the new
behavior possibly solve such problems?
> So I have chosen the BreezeDarkTheme for my preference and now I can't
edit myLeoSettings without loosing my preferred look and feel.
I don't have this problem. My copy of myLeoSettings.leo contains:
@string theme-name = EKRWindowsDark
Am I correct in assuming your myLeoSettings.leo contains:
@string theme-name = BreezeDarkTheme?
Another example quite recent is introducing new dock layout. As you can see
> from the previous screenshots my preference is to have outline in the top
> left and log underneath, and body on the right. Recently when I updated
> Leo, docks were introduced and I couldn't find the way to layout the docks
> to look like the screenshot above. So, I had to change all my Leo launchers
> to add --no-dock argument.
>
You probably have to make the body pane the central widget:
@string central-dock-widget = body
My point is, you have many times introduced changes that required users to
> change their settings or to give up updating Leo.
>
Adding docks to Leo was a major change. --no-docks makes it possible to
use Leo exactly as before. We spent weeks fixing bugs in the new code. You
could have asked for help at any time during this process.
I'm not sure why you have such problems with your settings. It should be
possible to fix them with Leo as it is.
You have argued that introducing a cache potentially can cause some
> confusion. Well I can agree that it is a possibility. But Leo already uses
> cache.
>
Yes, Leo does use a cache. --trace=cache will show you what it contains.
I've been looking at that a lot recently while I worked on the gui (global
docks) branch. At present, his cache is relatively benign because:
1. The cache contains a *small* amount of data, data that can be contained
*nowhere* else. Gui-related data, such as window position and arrangements
of docks, arises directly from moving or rearranging docks. This data does
not belong in an @settings tree.
2. The cache contains only non-essential data. Clearing the cache is thus
harmless.
3. The cache avoids polluting Leo outlines with non-essential data such
marks and expanded "bits".
When it needs a value of some setting it doesn't read all those outlines
> again and doesn't parse them again to retrieve the value, but instead it
> retrieves the value from the cache that was built during the startup. The
> difference is when this cache is built.
>
I am not convinced that this is an improvement. See below.
In my idea it is built (and updated too) whenever user changes any setting,
> and not during the startup.
>
At present, the user "changes" a setting only when saving an outline
(including leoSettings.leo and myLeoSettings.leo). As you imply, this does
not immediately update Leo's internal settings data.
That is why if implemented my idea will help to make things easier for
> users and allow them to see the effect of their changes immediately and not
> after the next reload. It would remove a lot of confusions that Leo at the
> moment imposes on users.
>
The reload-settings and reload-all-settings do (supposedly;-) update all
settings data.
If settings were the *only* thing that mattered, then these commands should
(in theory), suffice. Yes, in practice, there could be bugs.
However, settings are *NOT* the only things that matter. Settings,
especially theme-related settings, and plugin-related settings, have side
effects throughout Leo. Imo, your proposal has *no chance* of mitigating
these side effects.
My intention is not to impose my idea at any cost. I think this idea is a
> good one. It has several pros and all the cons you have pointed, I just
> don't see relevant.
>
> - It will not bring any inconvenience to users,
> - it will not remove any of Leo features,
> - it is not introducing a new caching mechanism because cache is
> already there. It just changes the time when this cache is built.
>
> Imo, putting all of Leo's settings into the cache accomplishes virtually
nothing. It will add code that must be debugged. Any discrepancy between
the cache and settings in the various Leo file will lead to unbounded
confusion.
The fundamental problem with this proposal is that* no caching scheme can
undo side effects arising Leo's myriad settings:*
*- *If reload settings doesn't work, neither will updating cached setting.
- If unloading a plugin doesn't work, neither will
updating @enabled-plugins.
The only reason to dismiss it, that I can still see, is that by accepting
> this idea you'd have to sacrifice one of your own, dear ideas and that is
> hard.
>
I have rejected them for the reasons stated. To summarize:
- Caching settings creates the potential for serious confusion.
- I particularly want to minimize the size of the cache.
- *Caching settings can not undo side effects.*
Leo's reload-settings command shows what is, and isn't, possible.
The *only* way to be sure of the effects of changing a settings is to
reload Leo fully.
If you don't want to discuss this idea any further, I won't insist either.
> Let's move on to something else. But if you ever wish to discuss it again,
> I'll be glad.
>
I think I now understand your original proposal more clearly. I still
think it's a bad idea. If you disagree with anything I have said here I am
willing to discuss this topic further.
This discussion does contain several worthwhile sub-topics:
- Difficulties with theme settings.
- Difficulties with dock settings.
- Difficulties with unloading plugins.
- A command to fully reload Leo.
pyzo has such a command, implemented in a few lines of code!
We can discuss these now, without having to imagine changing Leo's setting
machinery in any way.
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/CAMF8tS3QCT_OrQu%2B%2B%3DWp2yp75zkBS6HJRXAOLCJ-9AsU3mLvXA%40mail.gmail.com.
