On Thu, Feb 9, 2012 at 11:42 AM, Kent Tenney <[email protected]> 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 :-)
> 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
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
