On Fri, Feb 10, 2012 at 12:08 PM, Kent Tenney <[email protected]> wrote:
> 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 -- 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.
