On Fri, Feb 10, 2012 at 9:13 AM, Edward K. Ream <edream...@gmail.com> wrote:
> On Thu, Feb 9, 2012 at 11:42 AM, Kent Tenney <kten...@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
>
> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To post to this group, send email to leo-editor@googlegroups.com.
> To unsubscribe from this group, send email to
> leo-editor+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/leo-editor?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
