Leo's startup code must be simplified
Edward K. Ream
simplify it.
Now is the time to do it, while many of the details of configuration
handling are fresh in my mind.
This will not be a simple project: there are many complex details that
are simply unavoidable.
However, the present code is surely needlessly complex in several
respects. The most glaring is that Leo reads "local" files twice.
(Local files specified on the command line.) This creates difficult
complications for the configuration code: the configuration settings
read in the first read must somehow be "bridged" over to the commander
created in the second reading.
It's a mess. It happened, presumably, because the gui was once a user
setting. Now it's a command-line arg, which breaks a circular
dependency: Leo can now load files completely without knowing
settings.
Anyway, I have to take a detour and do this now. It may take several
days. I'll probably create a new LoadManager class to help hide the
details.
Edward
Edward K. Ream
> Leo's startup code is extremely complex. It is becoming urgent to
> simplify it.
switch to enable and disable code, I am using a unit test to create a
development environment. I pull code into the unit test and execute
that code using Alt-5.
This strategy is particularly important here. I expect some very
tricky dependencies, so I need to be able to to experiment freely on
*copies* of the code.
Edward
Edward K. Ream
leoSettings.leo and myLeoSettings.leo that I would like to fix.
Kent, and others interested in "creative" settings please take note.
Supposedly, the rules for finding settings files are at:
http://webpages.charter.net/edreamleo/customizing.html#search-order-for-settings-files
Here they are:
QQQQQ
When reading a .leo file, Leo looks for settings in default settings
files first, then settings in personal settings files, and finally
settings in local settings files. The exact search order is:
Default settings files:
configDir/leoSettings.leo
homeDir/leoSettings.leo
localDir/leoSettings.leo
Personal settings files:
configDir/myLeoSettings.leo
homeDir/myLeoSettings.leo
homeDir/<machine-name>LeoSettings.leo (note capitalization)
localDir/myLeoSettings.leo
Local settings files:
The file specified by the -c command-line option.
The file being loaded.
QQQQQ
This might be true for the first local file being loaded, but I
*think* that what happens for all other .leo files is that the
settings in the previously-found leoSettings.leo and myLeoSettings.leo
files are used *without* searching again for leoSettings.leo and
myLeoSettings.leo.
So it looks like the settings in effect for a particular local file
could depend on whether that file was loaded first or not.
Imo, searching localDir for settings is a good recipe for confusion.
Otoh, Kent may have made a (strong?) case for settings files in the
local directory (the directory containing the .leo file being loaded,
or rather the *first* .leo file being loaded).
But it seems hard to believe that the combination of settings files in
the home directory, plus the -c option, isn't sufficient to handle
just about any conceivable need. Furthermore, leoSettings.leo and
myLeoSettings.leo will be loaded from the local directory only if they
don't exist anywhere else. How likely is that? I always like to
avoid extremely rare cases: the confusion can be extreme when they
actually do happen.
Also, it should be made absolutely clear that Leo will load
leoSettings.leo and myLeoSettings.leo at most once.
Comments welcome, Amigos.
Edward
Edward K. Ream
> [It] seems hard to believe that the combination of settings files in
> the home directory, plus the -c option, isn't sufficient to handle
> just about any conceivable need.
I think there is a fairly elegant solution. For clarity, I'll discuss
myLeoSettings.leo, but similar remarks apply to leoSettings.leo. The
new scheme would be:
1. Use the myLeoSettings.leo file, wherever it is, if any
myLeoSettings.leo file is given on the command line. In the unlikely
event there are more than once myLeoSettings.leo files, the first one
wins.
2. Otherwise, look for myLeoSettings in the "standard places" but
*not* in the directory containing the first file given on the command
line.
I think this scheme is simple, intuitive, and flexible.
Edward
Kent Tenney
Reacting according to _my_ Leo world view.
I assume the existence of configDir/leoSettings.leo, but I
would never consider configDir/myLeoSettings.leo, because
if it's 'mine', what is it doing in Leo's source tree?
Similarly, I've never considered a leoSettings.leo file outside Leo's
source tree.
So, I basically could eliminate the leoSettings/myLeoSettings
dichotomy, if it's
outside the leoConfig/ dir, it's 'mine'.
So, to meet my needs, the search order could be when opening mydir/myfile.leo:
- leoConfig/leoSettings.leo # Edward's settings
- ~/.leo/leoSettings.leo # my system-wide settings
- leoSettings.leo in mydir/ # settings specific to this 'flavor' of Leo
- a file pointed to by -c <configfile> on the command line
- @settings node in myfile.leo # this file only
In theory a /etc/leo/leoSettings.leo file would be appropriate,
doubtful in practice.
>
> This might be true for the first local file being loaded,
So, 'first' is the file on the command line, 'not first' are files
opened via menu File -> Open ... ?
I would be ok if files opened from inside a Leo instance only considered
settings contained in the file being opened.
The limitations of previous statement would be mitigated if Leo
implemented native 'sessions' or 'projects' wherein I could call
Leo with a session name, the session consisting of the names
and current nodes of a set of Leo files.
Thanks,
Kent
but I
> *think* that what happens for all other .leo files is that the
> settings in the previously-found leoSettings.leo and myLeoSettings.leo
> files are used *without* searching again for leoSettings.leo and
> myLeoSettings.leo.
>
> So it looks like the settings in effect for a particular local file
> could depend on whether that file was loaded first or not.
>
> Imo, searching localDir for settings is a good recipe for confusion.
> Otoh, Kent may have made a (strong?) case for settings files in the
> local directory (the directory containing the .leo file being loaded,
> or rather the *first* .leo file being loaded).
>
> But it seems hard to believe that the combination of settings files in
> the home directory, plus the -c option, isn't sufficient to handle
> just about any conceivable need. Furthermore, leoSettings.leo and
> myLeoSettings.leo will be loaded from the local directory only if they
> don't exist anywhere else. How likely is that? I always like to
> avoid extremely rare cases: the confusion can be extreme when they
> actually do happen.
>
> Also, it should be made absolutely clear that Leo will load
> leoSettings.leo and myLeoSettings.leo at most once.
>
> Comments welcome, Amigos.
>
> Edward
>
> --
> You received this message because you are subscribed to the Google Groups "leo-editor" group.
> To post to this group, send email to leo-e...@googlegroups.com.
> To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
>
Edward K. Ream
> Reacting according to _my_ Leo world view.
I suspect that if you approve of a new settings scheme everyone else will too.
> I assume the existence of configDir/leoSettings.leo, but I would never consider configDir/myLeoSettings.leo, because if it's 'mine', what is it doing in Leo's source tree?
Similarly, I've never considered a leoSettings.leo file outside Leo's
source tree.
Interesting. The distinction between "mine" and "Leo's" is something
I never considered. I always thought of the distinction as being
between a "base" and an one or more "overrides". Still, your idea is
thought-provoking. I've tried to honor it in the following...
I am looking for "the simplest thing that could possibly work", both
at the code level, and at the "what is the simplest thing that would
please Kent" level :-)
> So, I basically could eliminate the leoSettings/myLeoSettings dichotomy, if it's outside the leoConfig/ dir, it's 'mine'.
It finally dawned on me what you were saying, namely that *all*
settings files could be called leoSettings.leo. Very interesting.
But I don't want to eliminate the *name* myLeoSettings.leo: the name
is useful, and besides it would cause documentation problems. It
would also change the entries in Leo's Help menu.
Let's see if we can get the effect of your suggestion without
eliminating the distinction between myLeoSettings.leo and
leoSettings.leo.
> So, to meet my needs, the search order could be when opening mydir/myfile.leo:
- leoConfig/leoSettings.leo # Edward's settings
- ~/.leo/leoSettings.leo # my system-wide settings
- leoSettings.leo in mydir/ # settings specific to this 'flavor' of Leo
- a file pointed to by -c <configfile> on the command line
- @settings node in myfile.leo # this file only
Reverse priority order.
I think we are getting close to some kind of agreement. But first...
===== Two details =====
1. At present, Leo allows users to specify a **machine directory**, a
directory to be searched if the desired settings file is not found in
your home directory. I don't remember who wanted this, but it's
probably unwise to omit this feature.
g.computeMachineName computes the machine directory something like this::
(
os.getenv('HOSTNAME') or
os.getenv('COMPUTERNAME') or
socket.gethostname()
)
2. The **configFile** is the file given by the -c option. This option
should work as before: it supplies an *additional* set of settings
that override the settings given in *both* leoSettings.leo and
myLeoSettings.leo. I suspect the recent code changes broke this
option. I also suspect nobody uses it, but you wanted it, Kent, and
we may as well keep it...
Hmm. As I write this I see there is a mini-problem. What happens if
the -c option specifies either a settings file (leoSettings.leo or
myLeoSettings.leo) that Leo is *already* using as a settings file? In
that case, I think Leo should ignore the -c option and issue a
warning.
===== Summary of proposed changes =====
Here are the changes I propose from the present scheme:
1. Leo will **not** look for leoSettings.leo or myLeoSettings.leo
**the local directory**, the directory containing the .leo file being
loaded. We don't want settings to depend on load order on the command
line!
2. If a path ending in leoSettings.leo appears on the command line,
Leo will use *that* file for leoSettings.leo: such a file will have
top priority in the search order. This allows the user to locate
leoSettings.leo *anywhere* on their machine, including the local
directory.
3. Similarly, a path ending in myLeoSettings.leo on the command line
takes top priority in the search for myLeoSettings.leo.
4. Leo will no longer search leo/config for myLeoSettings.leo by default.
===== Searching for leoSettings.leo =====
To summarize, Leo will look for leoSettings.leo in the following
priority order::
- Any path ending in leoSettings.leo given on the command line.
- User's home directory
- The machine directory
- Leo's config directory, leo/config
===== Searching for myLeoSettings.leo =====
- Any path ending in myLeoSettings.leo given on the command line.
- User's home directory
- The machine directory
Leo will no longer search leo/config for myLeoSettings.leo.
===== Handling the -c option =====
To summarize:
- Any .leo file given by the -c option is scanned for settings,
*regardless* of its name.
- Leo will ignore the -c option (and give a warning) if Leo is already
using the configFile for either leoSettings.leo or myLeoSettings.leo.
- Settings given by the -c option have highest priority: they override
settings in both leoSettings.leo and myLeoSettings.leo.
> So, 'first' is the file on the command line, 'not first' are files opened via menu File -> Open ... ?
Correct.
> I would be ok if files opened from inside a Leo instance only considered settings contained in the file being opened.
In essence, that is what happens. The base settings are in
leoSettings.leo. They are overridden by the settings in
myLeoSettings.leo. Any settings in the config file override the
result so far. Finally, the settings in the file being loaded
override all the other settings.
It's *essential* to understand that each commander (each Leo window)
has its *own* (completely separate) set of settings, computed as I
have just described. Loading another .leo file has *no* effect on the
settings calculated for previously-loaded .leo files.
Aside: things are more complicated for event handlers created by
plugins. No need to discuss that can of worms just now...
> The limitations of previous statement would be mitigated if Leo
> implemented native 'sessions' or 'projects' wherein I could call
> Leo with a session name, the session consisting of the names
> and current nodes of a set of Leo files.
An interesting idea. However, I think that scanning the command line
for paths ending in leoSettings.leo and myLeoSettings.leo gives
complete flexibility.
===== Summary =====
Kent, please let me know what you think. This is a surprisingly
interesting conversation.
I am rewriting the code that deals with settings files. This code
will separate the searches for leoSettings.leo and myLeoSettings.leo,
so we can freely modify the proposal above without causing any serious
code-level problems. In other words, I can move forward on the
rewrite while we continue our dialog.
Edward
Edward K. Ream
> > The limitations of previous statement would be mitigated if Leo
> > implemented native 'sessions' or 'projects' wherein I could call
> > Leo with a session name, the session consisting of the names
> > and current nodes of a set of Leo files.
>
> An interesting idea. However, I think that scanning the command line
> for paths ending in leoSettings.leo and myLeoSettings.leo gives
> complete flexibility.
one needs to avoid loading the setting file.
Suppose Leo supports two new command-line options, say::
--leo-settings=<path to any leo file>
--my-leo-settings=<path to any leo file>
These arguments would have "supreme" priority: they would supersede
even myLeoSettings.leo and leoSettings.leo files that appear in the
command line. Leo would use these settings files but would *not* load
them, unless they *also* appeared in the list of .leo files on the
command line.
In the new scheme, including myLeoSettings.leo and/or leoSettings.leo
in the list of loaded simply loads these files as usual. Such files
would have no effect on settings: they would be treated just as
ordinary loaded files, and they would use the settings in whatever
myLeoSettings.leo or leoSettings.leo files are in effect for all other
loaded files. This is actually a nice simplification.
This hardly seems like the simplest thing that could possibly work,
but it look likes a reasonable and least surprising scheme, and it
looks like the most flexible scheme. I'll do this unless someone
proposes a better way, or tells me why it's a bad idea.
Edward
Edward K. Ream
> This hardly seems like the simplest thing that could possibly work,
> but it look likes a reasonable and least surprising scheme, and it
> looks like the most flexible scheme. I'll do this unless someone
> proposes a better way, or tells me why it's a bad idea.
possibly work. This is the sole purpose of the present code rewrite.
Any design complications or improvements that arise from this
discussion will have virtually no effect on the average user, little
effect on the new code and only slight effect on Leo's documentation.
Edward
Kent Tenney
> On Thu, Feb 9, 2012 at 11:42 AM, Kent Tenney <kte...@gmail.com> wrote:
>
>> Reacting according to _my_ Leo world view.
>
> I suspect that if you approve of a new settings scheme everyone else will too.
>
>> I assume the existence of configDir/leoSettings.leo, but I would never consider configDir/myLeoSettings.leo, because if it's 'mine', what is it doing in Leo's source tree?
> Similarly, I've never considered a leoSettings.leo file outside Leo's
> source tree.
>
> Interesting. The distinction between "mine" and "Leo's" is something
> I never considered. I always thought of the distinction as being
> between a "base" and an one or more "overrides". Still, your idea is
> thought-provoking. I've tried to honor it in the following...
>
> I am looking for "the simplest thing that could possibly work", both
> at the code level, and at the "what is the simplest thing that would
> please Kent" level :-)
I think my expectations regarding configuration/settings are in line with
what seem to be "standard practice"
- application config (default settings)
Then a series of settings in narrowing scope:
- machine overrides
- user overrides
- project overrides
- command line overrides
- overrides in the file being opened
(I was about to say Leo is unique in the last one, but I've seen
lines in text files which tell Vim some settings)
The application config defines settings, and proceeding down the list,
settings are added, or if they already exist, they are overriden.
>
>> So, I basically could eliminate the leoSettings/myLeoSettings dichotomy, if it's outside the leoConfig/ dir, it's 'mine'.
>
> It finally dawned on me what you were saying, namely that *all*
> settings files could be called leoSettings.leo. Very interesting.
>
> But I don't want to eliminate the *name* myLeoSettings.leo: the name
> is useful, and besides it would cause documentation problems. It
> would also change the entries in Leo's Help menu.
>
> Let's see if we can get the effect of your suggestion without
> eliminating the distinction between myLeoSettings.leo and
> leoSettings.leo.
>
>> So, to meet my needs, the search order could be when opening mydir/myfile.leo:
>
> - leoConfig/leoSettings.leo # Edward's settings
> - ~/.leo/leoSettings.leo # my system-wide settings
> - leoSettings.leo in mydir/ # settings specific to this 'flavor' of Leo
> - a file pointed to by -c <configfile> on the command line
> - @settings node in myfile.leo # this file only
>
> Reverse priority order.
Reverse priority?
Ah, I see what you mean, the first (leoConfig/leoSettings.leo) is
lowest priority ...
I think of the list as a timeline, each item supplanting
or augmenting the previous.
>
> I think we are getting close to some kind of agreement. But first...
>
> ===== Two details =====
>
> 1. At present, Leo allows users to specify a **machine directory**, a
> directory to be searched if the desired settings file is not found in
> your home directory. I don't remember who wanted this, but it's
> probably unwise to omit this feature.
>
> g.computeMachineName computes the machine directory something like this::
>
> (
> os.getenv('HOSTNAME') or
> os.getenv('COMPUTERNAME') or
> socket.gethostname()
> )
>
> 2. The **configFile** is the file given by the -c option. This option
> should work as before: it supplies an *additional* set of settings
I guess my understanding is naive, I don't think in terms of *additional*
but in terms of *next*, expecting the settings machinery to be happy
with any number of settings collections, it just adds them if they didn't
exist, changes them if they did exist.
> that override the settings given in *both* leoSettings.leo and
> myLeoSettings.leo. I suspect the recent code changes broke this
> option. I also suspect nobody uses it, but you wanted it, Kent, and
> we may as well keep it...
>
> Hmm. As I write this I see there is a mini-problem. What happens if
> the -c option specifies either a settings file (leoSettings.leo or
> myLeoSettings.leo) that Leo is *already* using as a settings file? In
> that case, I think Leo should ignore the -c option and issue a
> warning.
Not sure how to interpret this, but my interest in -c <configfile> is like:
studying a package: I've written @buttons and @commands and @menus
which enhance Leo in ways specific to this package
$ leo myproject.leo -c project_customize.leo
>
> ===== Summary of proposed changes =====
>
> Here are the changes I propose from the present scheme:
>
> 1. Leo will **not** look for leoSettings.leo or myLeoSettings.leo
> **the local directory**, the directory containing the .leo file being
> loaded. We don't want settings to depend on load order on the command
> line!
? offering different settings in different directories is basic I think.
'command line'? I thought load order is known via
default -> machine -> home -> this dir -> -c configfile -> thefile.leo
>
> 2. If a path ending in leoSettings.leo appears on the command line,
> Leo will use *that* file for leoSettings.leo: such a file will have
> top priority in the search order. This allows the user to locate
> leoSettings.leo *anywhere* on their machine, including the local
> directory.
Not following.
in a command line, the filename after "-c" would be read for settings.
Since it is declared explicitly, why does the name matter?
The command line would be parsed such that one (at most) config
filename appeared after the "-c" option.
>
> 3. Similarly, a path ending in myLeoSettings.leo on the command line
> takes top priority in the search for myLeoSettings.leo.
I guess I'd say the search for leoSettings.leo and myLeoSettings.leo
should remain
automatic, "-c" on the command line is different, it's the one
explicit request to read
a settings file.
>
> 4. Leo will no longer search leo/config for myLeoSettings.leo by default.
Good.
>
> ===== Searching for leoSettings.leo =====
>
> To summarize, Leo will look for leoSettings.leo in the following
> priority order::
>
> - Any path ending in leoSettings.leo given on the command line.
I'd prefer any name, but specified by "-c <configfile>"
- I'd prefer retaining myLeoSettings.leo (or leoSettings.leo) in the current dir
> - User's home directory
> - The machine directory
> - Leo's config directory, leo/config
>
> ===== Searching for myLeoSettings.leo =====
>
> - Any path ending in myLeoSettings.leo given on the command line.
> - User's home directory
> - The machine directory
>
> Leo will no longer search leo/config for myLeoSettings.leo.
>
> ===== Handling the -c option =====
>
> To summarize:
>
> - Any .leo file given by the -c option is scanned for settings,
> *regardless* of its name.
Ah, ok, ignore previous request for this.
>
> - Leo will ignore the -c option (and give a warning) if Leo is already
> using the configFile for either leoSettings.leo or myLeoSettings.leo.
Right, though my naive expectations of settings is that no harm comes
from loading a settings file .. 10 times, each time it overrides the same
keys with the same values.
>
> - Settings given by the -c option have highest priority: they override
> settings in both leoSettings.leo and myLeoSettings.leo.
Good. (they are last, so they win)
>
>> So, 'first' is the file on the command line, 'not first' are files opened via menu File -> Open ... ?
>
> Correct.
>
>> I would be ok if files opened from inside a Leo instance only considered settings contained in the file being opened.
>
> In essence, that is what happens. The base settings are in
> leoSettings.leo. They are overridden by the settings in
> myLeoSettings.leo. Any settings in the config file override the
> result so far. Finally, the settings in the file being loaded
> override all the other settings.
>
> It's *essential* to understand that each commander (each Leo window)
> has its *own* (completely separate) set of settings, computed as I
> have just described. Loading another .leo file has *no* effect on the
> settings calculated for previously-loaded .leo files.
>
> Aside: things are more complicated for event handlers created by
> plugins. No need to discuss that can of worms just now...
>
>> The limitations of previous statement would be mitigated if Leo
>> implemented native 'sessions' or 'projects' wherein I could call
>> Leo with a session name, the session consisting of the names
>> and current nodes of a set of Leo files.
>
> An interesting idea. However, I think that scanning the command line
> for paths ending in leoSettings.leo and myLeoSettings.leo gives
> complete flexibility.
I was thinking this way:
- Leo has located, read and parsed all the settings stuff
and built a config object with them
- Leo gives this config object to each commander for
each file in the session/project
>
> ===== Summary =====
>
> Kent, please let me know what you think. This is a surprisingly
> interesting conversation.
>
> I am rewriting the code that deals with settings files. This code
> will separate the searches for leoSettings.leo and myLeoSettings.leo,
> so we can freely modify the proposal above without causing any serious
> code-level problems. In other words, I can move forward on the
> rewrite while we continue our dialog.
>
> Edward
>
Edward K. Ream
> I think my expectations regarding configuration/settings are in line with
> what seem to be "standard practice"
Yes, I think we are in basic agreement about this.
> The application config defines settings, and proceeding down the list,
> settings are added, or if they already exist, they are over-ridden.
Reasonable, but Leo uses a slightly modified scheme:
- base: leoSettings.leo, wherever it is
- next: myLeoSettings.leo, wherever it is.
- next: -c file
- last: settings in the local file, the file being loaded.
This is enough, imo.
> Reverse priority?
>
> Ah, I see what you mean, the first (leoConfig/leoSettings.leo) is
> lowest priority ...
>
> I think of the list as a timeline, each item supplanting or augmenting the previous.
Right. It's not exactly how Leo works, but close enough. But see below.
> I guess my understanding is naive, I don't think in terms of *additional*
> but in terms of *next*, expecting the settings machinery to be happy
> with any number of settings collections, it just adds them if they didn't
> exist, changes them if they did exist.
Again, this is *almost* what Leo does. The problem I have with
arbitrarily many settings files is that it just creates more and more
complexity. At present, we have *four* possible locations for
settings:
leoSettings.leo
myLeoSettings.leo
-c .leo file
the local file
This is already close to too many. We don't want to allow even more,
say by allowing *both* leoSettings.leo in the machine file and
leoSettings in the leo/config file. That would be over the top.
> Not sure how to interpret this, but my interest in -c <configfile> is like:
>
> studying a package: I've written @buttons and @commands and @menus
> which enhance Leo in ways specific to this package
>
> $ leo myproject.leo -c project_customize.leo
Iirc, we agreed months or years ago that the -c settings file should
be in *addition* to the other settings files. I plan to retain that
operation.
>> 1. Leo will **not** look for leoSettings.leo or myLeoSettings.leo
>> **the local directory**, the directory containing the .leo file being
>> loaded. We don't want settings to depend on load order on the command
>> line!
>
> ? offering different settings in different directories is basic I think.
>
> 'command line'? I thought load order is known via
> default -> machine -> home -> this dir -> -c configfile -> thefile.leo
Not quite. There are *two* search orders involved:
1. The order used to find leoSettings.leo and myLeoSettings.leo.
This is, roughly,
- A file specified by the (new) command-line options: --leo-settings
or --my-leo-settings
- (New: see below) the directory containing the .leo file being loaded
- Your home directory
- The machine directory
- leo/conf (only for leoSettings.leo)
2. The order used to resolve the value of any setting, **once the
locations of leoSettings.leo and myLeoSettings.leo are known**. This
order is.
leoSettings.leo -> myLeoSettings.leo -> -c configFile -> theFile.leo
The two search orders are completely different. Leo uses the *first*
search order during startup to create settings-related tables. These
tables embody the *second* search order. For example,
c.config.getBool uses those tables without knowing, or caring, how the
tables came to be.
>> 2. If a path ending in leoSettings.leo appears on the command line,
>> Leo will use *that* file for leoSettings.leo: such a file will have
>> top priority in the search order. This allows the user to locate
>> leoSettings.leo *anywhere* on their machine, including the local
>> directory.
>
> Not following.
> in a command line, the filename after "-c" would be read for settings.
> Since it is declared explicitly, why does the name matter?
I am talking about the *first* search order here. We want to
determine where to find leoSettings.leo and myLeoSettings.leo. The
point I was trying to make is that including leoSettings.leo or
myLeoSettings.leo on the command line does *not* change the (first)
search order in any way.
Otoh, the --leo-settings and --my-leo-settings arguments end the first
search immediately.
> The command line would be parsed such that one (at most) config
> filename appeared after the "-c" option.
Right. This affects the *second* search order, namely,
leoSettings.leo -> myLeoSettings.leo -> -c configFile -> theFile.leo
>> 3. Similarly, a path ending in myLeoSettings.leo on the command line
>> takes top priority in the search for myLeoSettings.leo.
This is no longer true. Maybe I forget to delete it. The
--my-leo-settings command-line option specifies the location of
myLeoSettings.leo exactly. End of story. As I said later, if
myLeoSettings.leo appears in the list of files to be loaded, Leo will
load myLeoSettings as it does any other .leo file.
> I guess I'd say the search for leoSettings.leo and myLeoSettings.leo
> should remain automatic, "-c" on the command line is different, it's the one
> explicit request to read a settings file.
Yes. The search for leoSettings.leo and myLeoSettings.leo uses the
*first* search order. There is no search order for -c configFiles:
the -c option must tell Leo exactly where to find the configFile. The
configFile itself is part of the *second* search order.
>> ===== Searching for leoSettings.leo =====
>>
>> To summarize, Leo will look for leoSettings.leo in the following
>> priority order::
>>
>> - Any path ending in leoSettings.leo given on the command line.
> I'd prefer any name, but specified by "-c <configfile>"
No. This confuses the first and second searches. -c configFiles have
very high priority in the *second* search order.
> - I'd prefer retaining myLeoSettings.leo (or leoSettings.leo) in the current dir.
Ah. I'm glad you said this (again). At present, leo only ever
computes the location of myLeoSettings.leo once. While reasonable, it
creates a problem: the *first* .leo file loaded on the command line
then determines the *global* myLeoSettings.leo used by *all other*
.leo files.
But as I write this, I see that it would be possible to *repeat* the
search for myLeoSettings.leo for *every* .leo loaded. This will be a
bit tricky, but it doesn't necessarily have to be slow: Leo could
remember the locations of all the myLeoSettings.leo files it has
found, and use the settings if one of the previously-loaded files
would be the "winning" myLeoSettings.leo file found under the first
set of search rules.
The point is that if the **local directory**, the containing the local
.leo file, also contains myLeoSettings.leo, then that
myLeoSettings.leo file would "win": it would be the myLeoSettings.leo
file in effect for that *particular* local .leo file. We could also
allow Leo to search for leoSettings.leo in the local directory.
I'm not promising to do this, but it might work cleanly. Certainly,
now is the time to consider doing it.
>> ===== Handling the -c option =====
>>
>> To summarize:
>>
>> - Any .leo file given by the -c option is scanned for settings,
>> *regardless* of its name.
>
> Ah, ok, ignore previous request for this.
All right. I think we are probably on the same page now.
>> - Leo will ignore the -c option (and give a warning) if Leo is already
>> using the configFile for either leoSettings.leo or myLeoSettings.leo.
>
> Right, though my naive expectations of settings is that no harm comes
> from loading a settings file .. 10 times, each time it overrides the same
> keys with the same values.
There is a design question here. Consider the second search order:
leoSettings.leo -> myLeoSettings.leo -> -c configFile -> theFile.leo
How are we to make sense of this if the configFile appears twice on
the list? My head wants to explode, so I think it best to avoid the
explosion and simply issue a warning ;-)
>> An interesting idea. However, I think that scanning the command line
>> for paths ending in leoSettings.leo and myLeoSettings.leo gives
>> complete flexibility.
I no longer believe this: hence the need for the --leo-settings and
--my-leo-settings command-line arguments.
> I was thinking this way:
> - Leo has located, read and parsed all the settings stuff
> and built a config object with them
> - Leo gives this config object to each commander for
> each file in the session/project
As the result of our conversation I am considering "recomputing" the
effective settings for *all* opened .leo files. This includes
possibly pulling in myLeoSettings.leo from the directory containing
the .leo file. So I think we are in basic agreement.
===== New summary =====
The big change in my thinking as the result of our conversation is
that Leo probably can search *anew* for myLeoSettings.leo (and
leoSettings.leo) every time Leo loads a .leo file. This will allow
Leo to find, in *all* cases, myLeoSettings.leo (and leoSettings.leo)
in the directory containing the loaded .leo file.
This shouldn't be burdensome. In most cases, the search will yield
previously-processed settings files, so no actual file reads will
happen and the computation of the final "effective" settings tables
will happen as it has always has.
I haven't written any code today, which is good, because I'll have to
generalize it a bit to handle this new code design.
Edward
Edward K. Ream
>>> - Leo will ignore the -c option (and give a warning) if Leo is already
>>> using the configFile for either leoSettings.leo or myLeoSettings.leo.
>>
>> Right, though my naive expectations of settings is that no harm comes
>> from loading a settings file .. 10 times, each time it overrides the same
>> keys with the same values.
>
> There is a design question here. Consider the second search order:
>
> leoSettings.leo -> myLeoSettings.leo -> -c configFile -> theFile.leo
>
> How are we to make sense of this if the configFile appears twice on
> the list? My head wants to explode, so I think it best to avoid the
> explosion and simply issue a warning ;-)
I doubt that the print-settings command knows about config files. It
probably should. If so, it will be useful to define the priority of
config files exactly, which means, I think, that -c files should
appear only once in the (second) search order.
EKR
Edward K. Ream
> ===== New summary =====
>
> The big change in my thinking as the result of our conversation is
> that Leo probably can search *anew* for myLeoSettings.leo (and
> leoSettings.leo) every time Leo loads a .leo file. This will allow
> Leo to find, in *all* cases, myLeoSettings.leo (and leoSettings.leo)
> in the directory containing the loaded .leo file.
does seem like a plausible thing to do, but I suspect it will cause a
fair amount of pain and very little gain.
Indeed, the simplest thing that could possibly work is the notion of a
*single* leoSettings.leo file and a *single* myLeoSettings.leo file to
be applied to all loaded .leo files in a particular session. This is
the way Leo has always worked. It's also the way lots of editors
work.
Suppose, for the sake of argument, that we allow multiple
leoSettings.leo and myLeoSettings.leo files in a single session. How
useful would it be? It's going to cause a ripple of complications.
For example, the show-settings command would now have to report
*which* settings files are being used, and worse, the user must pay
attention! I don't think this is progress.
To repeat, this is a close call. Kent has given an example where
loading myLeoSettings.leo from the local directory could be somewhat
useful. But it doesn't seem *that* useful, and the additional
complications seem like sufficient reason not to do it.
Stepping back, I started the rewrite of the configuration code because
I had no real choice: the present code is buggy and almost impossible
to understand. However, I would like to make minimal changes to how
Leo actually works. Imo, the -c option, and the new --leo-settings
and --my-leo-settings options, should handle almost any conceivable
situation. True, command-line options aren't quite as convenient as
automatically finding settings files, but I think they are good
enough.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> > The big change in my thinking as the result of our conversation is
> > that Leo probably can search *anew* for myLeoSettings.leo (and
> > leoSettings.leo) every time Leo loads a .leo file. This will allow
> > Leo to find, in *all* cases, myLeoSettings.leo (and leoSettings.leo)
> > in the directory containing the loaded .leo file.
>
> On third thought, I am not wild about this. It's a close call, and it
> does seem like a plausible thing to do, but I suspect it will cause a
> fair amount of pain and very little gain.
I favor more flexible solutions - i.e. one which allows all the .leo
files in a folder to behave like some sort of customized app. because
of the myLeoSettings.leo in that folder.
But I wonder if we're discussing a preference here - is there some way
to make the list of places to look a @setting?
Maybe that's a boot strapping problem though, a fresh vanilla download
won't necessarily find the @setting telling it where to look for
@settings, unless the default value is fairly promiscuous, and
shortening the list of places to look because the custom personal
setting.
Cheers -Terry
Kent Tenney
@include
\
/path/to/settingsfile
and the subtrees of @settings nodes in <settingsfile>
would be slurped in?
On Fri, Feb 10, 2012 at 4:14 PM, Edward K. Ream <edre...@gmail.com> wrote:
> On Feb 10, 3:39 pm, "Edward K. Ream" <edream...@gmail.com> wrote:
>
>> ===== New summary =====
>>
>> The big change in my thinking as the result of our conversation is
>> that Leo probably can search *anew* for myLeoSettings.leo (and
>> leoSettings.leo) every time Leo loads a .leo file. This will allow
>> Leo to find, in *all* cases, myLeoSettings.leo (and leoSettings.leo)
>> in the directory containing the loaded .leo file.
>
> On third thought, I am not wild about this. It's a close call, and it
> does seem like a plausible thing to do, but I suspect it will cause a
> fair amount of pain and very little gain.
>
> Indeed, the simplest thing that could possibly work is the notion of a
> *single* leoSettings.leo file and a *single* myLeoSettings.leo file to
> be applied to all loaded .leo files in a particular session. This is
> the way Leo has always worked. It's also the way lots of editors
> work.
I think this would be adequate if myLeoSettings.leo came from
the local directory.
>
> Suppose, for the sake of argument, that we allow multiple
> leoSettings.leo and myLeoSettings.leo files in a single session. How
> useful would it be? It's going to cause a ripple of complications.
> For example, the show-settings command would now have to report
> *which* settings files are being used, and worse, the user must pay
> attention! I don't think this is progress.
Right. I should never have to (or be expected to) change the default
leoSettings.leo, it creates version conflicts for one thing.
A single myLeoSettings.leo provides my preferences, probably
should be in $HOME or $HOME/.leo
The remaining piece is a file which provides domain-specific
customization of this editing session. It could come from a
file in the current directory or command line.
(I like that: @settings provided are: defaults, preferences, customizations)
>
> To repeat, this is a close call. Kent has given an example where
> loading myLeoSettings.leo from the local directory could be somewhat
> useful. But it doesn't seem *that* useful, and the additional
> complications seem like sufficient reason not to do it.
>
> Stepping back, I started the rewrite of the configuration code because
> I had no real choice: the present code is buggy and almost impossible
> to understand. However, I would like to make minimal changes to how
> Leo actually works. Imo, the -c option, and the new --leo-settings
> and --my-leo-settings options, should handle almost any conceivable
> situation. True, command-line options aren't quite as convenient as
> automatically finding settings files, but I think they are good
> enough.
>
> Edward
>
Edward K. Ream
> is there some way to make the list of places to look a @setting?
Only on the command line.
When I awoke this morning I saw the way forward.
1. The -c option must go. It's a bad idea and nobody uses it.
Similarly, the --leo-settings and --my-leo-settings options are bad
ideas. None of these options are worth the time to document, much
less implement.
2. Leo *will* look in the local directory for myLeoSettings.leo, but
not leoSettings.leo. This will give almost all the advantages of the
-c option, with the added advantage that somebody, somewhere, might
actually use this feature.
**Footnote**: Leo will (as at present), load at most one
myLeoSettings.leo file per session: Leo will determine the local
directory using the path to the first loaded .leo file on the command
line. This works well in practice because the startup messages always
make clear where settings are coming from.
The take away message is that simplicity matters. Specifying the
location of settings files on the command line is featuritis.
I welcome comments, but I don't think anyone is going to change my
mind. Our lengthy conversation has been rewarded with a cleaner
design.
Edward