Let straighten out the settings mess

[Edward K. Ream]

Imo, Leo 4.5 b4 should attempt to handle settings in a more standard
manner.

The question is, what is that, exactly?

At present, I think that people are complaining about
seeing .leoID.txt and myLeoSettings.leo in their home directory.

I was under the impression that files starting with '.' are typically
hidden in Linux. Is this not correct?

I am worried that looking for home/.leo/myLeoSettings.leo is going to
break lots of people's installations. I suppose Leo could continue to
look for home/myLeoSettings.leo.

So please tell me exactly what you want Leo to do...

Edward

[Alia K]

+1 for the following unix-like structure for per user leo settings:

$HOME/.leo
leoID.txt
myLeoSettings.leo
etc..

This is consistent with most other unix/linux apps, and even popular
python programs such as ipython which places its settings in
$HOME/.ipython

IMHO, moving / renaming myLeoSettings.leo to the new structure is a
small price for users to pay... and sure beats the hell out of
constantly deleting $HOME/myLeoSettings.leo (as I am currently
doing :-)

Alia

[Terry Brown]

On Sat, 16 Aug 2008 10:14:07 -0700 (PDT)
"Edward K. Ream" <edre...@gmail.com> wrote:

> I was under the impression that files starting with '.' are typically
> hidden in Linux. Is this not correct?

That's correct, by convention files and dirs starting with . are
ignored by file selection dialogs and even * as a wildcard.

If you've changed the default setting on file opening preferences etc.
then you may be seeing . files, but usually you don't.

> I am worried that looking for home/.leo/myLeoSettings.leo is going to
> break lots of people's installations. I suppose Leo could continue to
> look for home/myLeoSettings.leo.
>
> So please tell me exactly what you want Leo to do...

Someone mentioned something about mySettings.leo being created
automatically, but I don't think it is, right? Maybe that's not a key
point.

I'm all for a .leo directory. Seems to me there are two choices:

1) Leo tries to be smart and looks for both ~/[my]leoSettings.leo and
~/.leo/[my]leoSettings.leo, uses which ever it finds and complains very
loudly if it finds both.

2) Change the default behavior so it always looks in ~/.leo, but for
some transitional period (a year or two?) check for them in ~ and
complain loudly telling the user to move them - force the user to move
them by ignoring them and just explaining the problem. I.e. "I found
you config file but I'm not using it because it's in the wrong place".

I favor option (2) because (1) has issues like
<hostname>LeoSettings.leo.

Cheers -Terry

[Peter Bienstman]

Alia K wrote:
> +1 for the following unix-like structure for per user leo settings:
>
> $HOME/.leo
> leoID.txt
> myLeoSettings.leo
> etc..
>

Make that +2.

Peter

[Terry Brown]

One issue though - myLeoSettings.leo in some arbitrary directory.
Should that be in .leo in that directory (would match .bzr etc.) or
in .myLeoSettings.leo, or the current myLeoSettings.leo? I guess I
lean towards .leo directory.

Cheers -Terry

[Terry Brown]

Which would suggest that .leo_shadow should be .leo/shadow...

> Cheers -Terry
>
> >

[Peter Bienstman]

Terry Brown wrote:

> Which would suggest that .leo_shadow should be .leo/shadow...

Not sure if that's a good idea. The way it is now, I could add shadow
directories to a repository. If at at certain point in time one of my
co-developers wants to try out Leo, everything is already in place in
his local copy of the tree. This would be difficult if the shadow
directory were in my home directory.

Peter

[Terry Brown]

Sure, I wasn't talking about HOME/.leo, but what Kent's been calling
CWD/myLeoSettings.leo. I.e. the file that's checked for settings in
the directory of the file being opened.

I'm suggesting that that could be in a .leo directory in the
project directory containing main.leo or whatever. But then rather than
Leo having .leo_shadow/ and .leo/ in the project directory, it could
have just .leo/, which contains shadow/ and myLeoSettings.leo

So if I were starting from scratch at this point, locations I'd use
would be:

INSTALL/ = the directory containing runLeo.py, i.e. core/
HOME/ = obvious
PROJECT/ = dir containing some project's leo file, say main.leo
IRRELEVANT/ = dir which is current when python is started

It doesn't matter whether 'INSTALL/' is core/ or one of its ancestors,
define it how you want and adjust the relative paths below.

cd IRRELEVANT/
python INSTALL/../../launchLeo.py main.leo

leo now checks for settings, in this order

INSTALL/../config/leoSettings.leo
HOME/.leo/leoSettings.leo
PROJECT/.leo/leoSettings.leo
INSTALL/../config/myLeoSettings.leo
HOME/.leo/<hostname>LeoSettings.leo
HOME/.leo/myLeoSettings.leo
PROJECT/.leo/myLeoSettings.leo
PROJECT/main.leo

and if main.leo contains shadow files, leo uses

PROJECT/.leo/shadow

like I said, "if I were starting from scratch at this point".

You could argue there's no need for "HOME/.leo/leoSettings.leo" and
"PROJECT/.leo/leoSettings.leo". But rather than remove that, just
don't use it, unless you have some obscure need to.

Cheers -Terry

[Ville M. Vainio]

But as it is now, you require write access to the directory where the
files are. Not optimal for all situations...

--
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'

[Randy Kramer]

This is a little off the current point, but if someone is going to reconsider
where settings and data will reside, you may want to look into the XDG Base
Directory Specification
(http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html).

I say this slightly tongue in cheek as I find it somewhat confusing at this
point, at least partially because some people who have implemented it have
implemented it in ways that seem strange to me.

For example, instead of using $XDG_DATA_HOME and $XDG_DATA_DIRS for what I
would consider "real" user data (for example, Leo "content" files--i.e.,
files containing user (created) content) some implementors (I can't recall
which, atm) have used those for things like files containing icons used by
the application. That's not what I expected when I read the spec.

I thought these directories were also covered in the Filesystem Hierarchy
Standard (e.g., http://www.pathname.com/fhs/pub/fhs-2.3.html), but when I
went looking for them today I couldn't find them.

I am not an expert in this subject--I just know that this effort is going on,
and you may want to align your efforts with theirs.

Another consideration I'd like to suggest is keeping the locations of the
config and things like the shadow files configurable by some means. I (for
one) do not like to have my user data (text files, pictures, mp3s, ...) mixed
with application configuration data, even if it is hidden (by a leading .).
So, at the present time, I keep all my "real" data in another directory tree
(/rhk) and let applications store their configuration data in ~/.

On Sunday 17 August 2008 02:23 pm, Terry Brown wrote:
> Sure, I wasn't talking about HOME/.leo, but what Kent's been calling

Randy Kramer
--
"I didn't have time to write a short letter, so I created a video
instead."--with apologies to Cicero, et.al.

[Edward K. Ream]

On Sun, Aug 17, 2008 at 4:01 PM, Randy Kramer <rhkr...@gmail.com> wrote:
>
> This is a little off the current point, but if someone is going to reconsider
> where settings and data will reside, you may want to look into the XDG Base
> Directory Specification

I think we have enough good ideas for now :-)

Edward

[Edward K. Ream]

On Aug 16, 12:14 pm, "Edward K. Ream" <edream...@gmail.com> wrote:

> Imo, Leo 4.5 b4 should attempt to handle settings in a more standard
> manner.

Many thanks to all who have offered suggestions and comments. The
following post summarizes my present plans.

1. Everyone seems agree that the following structure for settings
files is good:

$HOME/.leo
leoID.txt
myLeoSettings.leo
etc..

2. (controversial?) There is a question of what to do about $HOME/
myLeoSettings.leo. I don't like either of the following suggestions:

QQQ

1) Leo tries to be smart and looks for both ~/[my]leoSettings.leo
and
~/.leo/[my]leoSettings.leo, uses which ever it finds and complains
very
loudly if it finds both.

2) Change the default behavior so it always looks in ~/.leo, but
for
some transitional period (a year or two?) check for them in ~ and
complain loudly telling the user to move them - force the user to
move
them by ignoring them and just explaining the problem. I.e. "I
found
you config file but I'm not using it because it's in the wrong
place".

QQQ

1) will just cause more confusion, and 2) just delays the "day of
transition" to a time when we've all forgotten the issues
involved :-) Imo, the thing to do is simply to make the transition
*now*, and get the pain over with. Leo can, without confusion, warn
that it is ignoring $HOME/.myLeoSettings.leo.

3. (controversial?) The present code creates myLeoSettings.leo if it
doesn't exist. I don't like it, and it has already created
installation problems. This should be an option, but it can't be an
option because creating myLeoSettings.leo happens too early.

So I'm going to take out this code. A create-my-leo-settings-leo
command might be helpful...

So much for configuration settings, per se.

Let us now consider the question of directories for Leo's shadow
files.

1. The suggestion was to change .leo_shadow to .leo/shadow. This may
be possible now::

@string shadow_subdir = .leo/shadow

I'll make sure Leo's code makes this possible.

2. Ville makes an important observation re Linux:

"as it is now, you require write access to the directory
where the files are. Not optimal for all situations..."

You could call this a problem with the original @shadow idea. I don't
know of a real solution to this problem.

Imo, putting shadow file in a centralized location (the exact location
is irrelevant) is a wretched idea: it will add complexity, obscurity
and bugs not only to the code, but for users. I will never agree to
such a scheme. So I think the only thing for people to do is to
put .leo files that use @shadow in a writable directory :-) This is
the down side of Linux's security scheme.

Please comment now. I'll probably push revisions based on these
remarks tomorrow.

Edward

[Terry Brown]

On Wed, 20 Aug 2008 07:46:41 -0700 (PDT)

"Edward K. Ream" <edre...@gmail.com> wrote:

> 1) will just cause more confusion, and 2) just delays the "day of
> transition" to a time when we've all forgotten the issues
> involved :-) Imo, the thing to do is simply to make the transition
> *now*, and get the pain over with. Leo can, without confusion, warn
> that it is ignoring $HOME/.myLeoSettings.leo.

Apart from the fact you meant "$HOME/myLeoSettings.leo" :) I (the
source of (1) and (2)) agree - better to just insist on the correct
location and yell at the user, than to allow either.

> 3. (controversial?) The present code creates myLeoSettings.leo if it
> doesn't exist. I don't like it, and it has already created
> installation problems. This should be an option, but it can't be an
> option because creating myLeoSettings.leo happens too early.

Creating config files in a users home dir if not present is very common
practice, I've never really seen it cause problems. It amuses me that
I have config for apps I haven't used for 10-12 years, while Windows
struggles to get your settings through a single upgrade without losing
them :-)

> So I'm going to take out this code. A create-my-leo-settings-leo
> command might be helpful...

I didn't see the installation problem, but I can't imagine why creating
if not present doesn't work for leo when it works for so many other
apps. However if you are going to stop doing that, then I think the
menu command "edit settings" should create it (if needed), then edit it.

> So much for configuration settings, per se.

What about the so called CWD/myLeoSettings.leo, I assume that moves to
CWD/.leo/myLeoSettings.leo? Along with CWD/.leo/shadow I think that
would be tidiest.

Cheers -Terry

[Randy Kramer]

On Wednesday 20 August 2008 10:46 am, Edward K. Ream wrote:
> 1. Everyone seems agree that the following structure for settings

^Almost

Just for the record ;-)

[Edward K. Ream]

On Wed, Aug 20, 2008 at 10:10 AM, Terry Brown <terry_...@yahoo.com> wrote:
> It amuses me that
> I have config for apps I haven't used for 10-12 years, while Windows
> struggles to get your settings through a single upgrade without losing
> them :-)

The configuration problem happened on Linux: replacing a link.

Edward

[Edward K. Ream]

On Aug 20, 10:31 am, Randy Kramer <rhkra...@gmail.com> wrote:

> 1.  Everyone seems agree that the following structure for settings
>       ^Almost

True, brevity is a virtue, but this is too brief. If you have
objections please state them clearly.

Edward

[Kent Tenney]

On Wed, Aug 20, 2008 at 10:10 AM, Terry Brown <terry_...@yahoo.com> wrote:
>

And, according to convention on *nix AFAICT

Especially now that Leo has shadow files, I think people will be
unsurprised to see Leo config and private in company like:
ls -a
.leo
.bzr
.svn
.vim
.cvs

>
> Cheers -Terry
>
> >
>

[Edward K. Ream]

On Wed, Aug 20, 2008 at 11:36 AM, Kent Tenney <kte...@gmail.com> wrote:

> Especially now that Leo has shadow files, I think people will be
> unsurprised to see Leo config and private in company like:
> ls -a
> .leo
> .bzr
> .svn
> .vim
> .cvs

Oh good :-)

Edward

[Randy Kramer]

Sorry!

I stated (or implied / tried to state) my concerns in an earlier post, those
being:

* consider the XDG Base Directory Specification
(http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html)
* keep the locations configurable (so that real user data and configuration
data can be separated sometime in the future)

The approach you are headed towards is pretty much the current standard Linux
approach, so how can I argue that it is not appropriate.

I am tilting at windmills advocating for what I think is a better approach,
one which I think will come to pass sooner or later.

So, I had trouble allowing myself to be grouped with the "Everyone" that
"seems to agree", and I'm just stating that I don't--but not expecting any
change based on my lack of agreement.

Hmm, it seems like I could have said this more simply and clearer, and Im just
making noise. Sorry about that.

regards,

[Edward K. Ream]

On Wed, Aug 20, 2008 at 7:15 PM, Randy Kramer <rhkr...@gmail.com> wrote:

>> True, brevity is a virtue, but this is too brief. If you have
>> objections please state them clearly.
>
> Sorry!

No problem. Just remember that I get many emails every day on many
subjects. Please always quote a previous statement to set context.

> The approach you are headed towards is pretty much the current standard Linux
> approach, so how can I argue that it is not appropriate.

I'm typically looking for the simplest thing that could possibly work.

> I am tilting at windmills advocating for what I think is a better approach,
> one which I think will come to pass sooner or later.

To have any chance of convincing me, you would have to show why the
different approach is a) better than Leo's already flexible
configuration way and b) worth the trouble to implement.

Edward

[Ville M. Vainio]

On Thu, Aug 21, 2008 at 2:32 PM, Edward K. Ream <edre...@gmail.com> wrote:

> To have any chance of convincing me, you would have to show why the
> different approach is a) better than Leo's already flexible
> configuration way and b) worth the trouble to implement.

And c) equally applicable/better for windows users.

[Randy Kramer]

On Thursday 21 August 2008 07:32 am, Edward K. Ream wrote:
> To have any chance of convincing me, you would have to show why the
> different approach is a) better than Leo's already flexible
> configuration way and b) worth the trouble to implement.

Edward,

Thanks for offering that opportunity, but I simply don't have the resources to
do that at this time. The direction you're headed is a fine one and
appropriate, as it is, in line with the current approach used in Linux.

I simply *wish* it was something different.

Peace!

[Kent Tenney]

If Leo is using a .leo directory, maybe the filenames could
be shortened, possibly even just settings.leo

Convention seems to favor terse.

Another convention seems to be offering a final customization option,
"-c" on the command line.

/path/to/leo/RunLeo.py -c /my/special/configdir/settings.leo myfile.leo

I think the file named by -c would effectively act as CWD/.leo/settings.leo
replacing it if it exists.

The settings in myfile.leo would always have the last word.

>
> Edward
>
> >
>

[Randy Kramer]

On Thursday 21 August 2008 08:20 am, Ville M. Vainio wrote:
>
> On Thu, Aug 21, 2008 at 2:32 PM, Edward K. Ream <edre...@gmail.com> wrote:
>
> > To have any chance of convincing me, you would have to show why the
> > different approach is a) better than Leo's already flexible
> > configuration way and b) worth the trouble to implement.
>
> And c) equally applicable/better for windows users.

I haven't paid enough attention, but is the planned approach equally
applicable to windows? I see (remember) so many differences in the directory
structure and configuration approach (between Windows and Linux--the Windows
registry for example), that it would be hard to believe. (On the other hand,
there is usually a high enough perspective from which similarities in almost
anything can be perceived.)

But, my request was only that:
* consider the new Linux standards that are being developed (the $XDG
stuff) and implemented so far in only a few cases (and rather confusing at
that, at least to me, because the implementations I've seen don't match my
interpretation of the specifications, nor do they all match)
* keep it (easily) configurable, so renegades like me can adjust it to suit
(I guess it will be in any case, I mean, I guess I can use symlinks to get
stuff out of my ~/ --I'm sure I've tried that at one time or another, and I
know I ran into some problems, but those may have been partially due to my
inexperience at the time (and I can't immediately remember what they are))

I don't intend to beat a dead horse, the planned direction seems appropriate,
and I'm going to cap my pen. ;-)

[Edward K. Ream]

On Aug 16, 12:14 pm, "Edward K. Ream" <edream...@gmail.com> wrote:

> Imo, Leo 4.5 b4 should attempt to handle settings in a more standard
> manner.

The first config changes are at rev 883 of the trunk.

Leo now handle's @enabled-plugins nodes in a more straightforward
manner: it enables all plugins mentioned in the body text, and
completely ignores comments. Thus, the presence of a plugin in a
comment does not disable the plugin.

Edward

[Edward K. Ream]

On Aug 16, 12:39 pm, Alia K <alia_kho...@yahoo.com> wrote:
> +1 for the following unix-like structure for per user leo settings:
>
> $HOME/.leo
>     leoID.txt
>     myLeoSettings.leo
>     etc..

rev 891 now uses this directory structure for all files that were
formerly in the $HOME directory. Leo will create the .leo sub-
directory as needed, but Leo will not copy files from $HOME to
$HOME/.leo.

The easiest way to convert to the new scheme is to create the
$HOME/.leo yourself, and then move files from $HOME to $HOME/.leo.
That should give you exactly the same behavior as before. Otherwise,
Leo may prompt you for the leoID.txt file, and my use
myLeoSettings.leo found in other places.

This is likely to be the last substantial change before Leo 4.5
final. I expect to release Leo 4.5 b4 on Monday and possibly Leo 4.5
final on Friday. Please report any problems immediately.

Edward

[Kent Tenney]

Just a recap.

given the following myLeoSettings.leo files:

home/.leo/myLeoSettings.leo
home/myLeoSettings.leo
<cwd>/.leo/myLeoSettings.leo
<cwd>/myLeoSettings.leo

I get the following:
reading settings in /home/ktenney/src/leo-editor/leo/config/leoSettings.leo
reading settings in /home/ktenney/.leo/myLeoSettings.leo
reading settings in /home/ktenney/work/docubi/myLeoSettings.leo
reading settings in /home/ktenney/work/docubi/start.leo

indicating that;

home: ONLY the home/.leo dir is searched, not home/
cwd: ONLY the 'cwd' dir is searched, not cwd/.leo

Is this expected?, documented?

The difference between behaviour in home/ and cwd/ will trip
me up, I'll forget which is handled how.

Thanks,
Kent

[Edward K. Ream]

On Tue, Sep 9, 2008 at 10:55 AM, Kent Tenney <kte...@gmail.com> wrote:
>
> Just a recap.
>
> given the following myLeoSettings.leo files:
>
> home/.leo/myLeoSettings.leo
> home/myLeoSettings.leo
> <cwd>/.leo/myLeoSettings.leo
> <cwd>/myLeoSettings.leo
>
> I get the following:
> reading settings in /home/ktenney/src/leo-editor/leo/config/leoSettings.leo
> reading settings in /home/ktenney/.leo/myLeoSettings.leo
> reading settings in /home/ktenney/work/docubi/myLeoSettings.leo
> reading settings in /home/ktenney/work/docubi/start.leo
>
> indicating that;
>
> home: ONLY the home/.leo dir is searched, not home/
> cwd: ONLY the 'cwd' dir is searched, not cwd/.leo

Yes, this is expected. I don't want Leo creating .leo directories
except in the home directory.

As far as being documented, I just changed chapter 8 so it says:

Leo stores options in ``@settings`` trees, that is, parts of Leo
outlines whose root
node has the headline ``@settings``. When opening a .leo file, Leo looks for
``@settings`` trees in the following places:

- The file ``leoSettings.leo`` in the leo/config directory.
- The file ``leoSettings.leo`` in the user's home/.leo directory.
- The file ``myLeoSettings.leo`` in the leo/config directory.
- The file ``myLeoSettings.leo`` in the user's home/.leo directory.
- The file being loaded.

I think that is close enough to the truth.

Edward

[Kent Tenney]

:-]

I think closer to the truth would be better.

You have not mentioned cwd/myLeoSettings.leo, which seems
to be ignored UNLESS home/.leo/myLeoSettings.leo is NOT found.

I think 'close enough' requires that at least the
documentation match the behaviour, otherwise
there's potential for wasting a lot of time trying
to figure out what is going on.

Thanks,
Kent

>
> Edward
>
> >
>

[Edward K. Ream]

On Tue, Sep 9, 2008 at 1:17 PM, Kent Tenney <kte...@gmail.com> wrote:

> I think 'close enough' requires that at least the

> documentation match the behavior, otherwise

> there's potential for wasting a lot of time trying
> to figure out what is going on.

I agree. Is there a mismatch at present?

However, I think we have different attitudes towards configuration. I
am looking for the simplest approach that could possibly work. Imo,
the standard way fits this criterion. The default settings are in
config/leoSettings.leo, the users overrides are in
home/.leo/myLeoSettings.leo, and all other tweaks are in the .leo
files being opened. This organization, in combination with
@ifplatform and @ifhostname trees, should be flexible enough for
everyone.

Trying to make sense of every possible permutation and combination of
multiple leoSettings.leo and myLeoSettings.leo nodes in all possible
directories will be a thankless task. The docs, even if accurate, it
would be neither clear nor helpful.

Edward

[Kent Tenney]

I thought Leo obeyed this simple rule:

- the last setting read is used (plugins are a bit special)

Is this true?

If so, all possible permutation and combinations is strictly a matter of
which files are read, and in which order.

Currently it seems to be;
- leo/src/config/leoSettings.leo
- home/.leo/myLeoSettings.leo
- cwd/myLeoSettings.leo
- current file

The doc you described a couple posts back doesn't mention cwd/myLeoSettings.leo,
and there seems to be ambiguity around the behaviour of
home/.leo/myLeoSettings.leo vs home/myLeoSettings.leo

The continued confusion on this point leads me to believe I'm
missing something, but I'm not sure what it is.

I've got a bulldog grip on @settings, won't let go.
I think they're the key.

Thanks,
Kent

>
> Edward
>
> >
>

[Edward K. Ream]

On Wed, Sep 10, 2008 at 10:00 AM, Kent Tenney <kte...@gmail.com> wrote:

> I thought Leo obeyed this simple rule:
>
> - the last setting read is used (plugins are a bit special)
>
> Is this true?

True.

> If so, all possible permutation and combinations is strictly a matter of
> which files are read, and in which order.

True, but it seems needlessly confusing to have more than one
myLeoSetting.leo file being "active" at any one time.

> Currently it seems to be;
> - leo/src/config/leoSettings.leo
> - home/.leo/myLeoSettings.leo
> - cwd/myLeoSettings.leo
> - current file
>
> The doc you described a couple posts back doesn't mention cwd/myLeoSettings.leo,
> and there seems to be ambiguity around the behaviour of
> home/.leo/myLeoSettings.leo vs home/myLeoSettings.leo

I mis-remembered the exact rule, which is implicitly defined in the node:

Code-->Core classes-->@thin leoConfig.py-->class
configClass-->Scanning @settings
(g.app.config)-->g.app.config.readSettingsFiles & helpers

It appears that Leo will, in fact, read all the settings files in the
table, so it is possible to have several myLeoSettings.leo files being
active. And yes, I suspect that cwd gets searched. But I don't
expect to remember the exact details for more than 5 minutes, and I
don't expect anyone else to know or care about these details either.

You are making my main point for me: if you have lots of settings
files lying around, you *will* get confused no matter how good my
documentation. People just are not good at making sense of a huge
number of choices.

The path to clarity is to voluntarily limit your choices: pick *one*
place (home/.leo) for your myLeoSettings.leo file, and *one* place
(leo/config) for your leoSettings.leo file.

Edward

[Terry Brown]

On Wed, 10 Sep 2008 10:53:15 -0500

"Edward K. Ream" <edre...@gmail.com> wrote:

> The path to clarity is to voluntarily limit your choices: pick *one*
> place (home/.leo) for your myLeoSettings.leo file, and *one* place
> (leo/config) for your leoSettings.leo file.

Yes but :-) home/.leo/myLeoSettings.leo is for personal leo settings,
but cwd/myLeoSettings.leo can be used to customize the behavior of .leo
files in cwd, which is an important feature if Leo is going to be
highly configurable for different applications.

Cheers -Terry

[Edward K. Ream]

All right. Is there anything except documentation that should change?

Edward

[Kent Tenney]

Such enthusiasm!

:-]

> Is there anything except documentation that should change?

Personally, I'd like to see:

- determine the optimal configuration behaviour
- implement it
- provide tests for it
- document it

Maybe this is already done, however I think there are untested cases,
I spend quite a bit of time fussing with configuration surprises.

Personally, I'd like to see another config file available via -c on
the command line:
(a common idiom)

leo myproject.leo -c /usr/lib/myproject/myLeoSettings.leo

or better yet:

leo myproject.leo -c /etc/leo/style01.leo
leo myotherproject.leo -c /etc/leo/style02.leo
leo anotherproject.leo -c /etc/leo/style23.leo

Each file opens in an editor with the shortcuts, buttons, commands,
plugins, appearance etc. that has been tuned for that data management task.

or best yet:

leo myproject.leo -c /usr/lib/python2.5/site-packages/leo/config/style94.leo

the Leo community contributes their brilliance to a library of settings files.

When I look at Leo I see a platform to build with, and as such,
the @settings are akin to source code, extremely important.

Thanks,
Kent

>
> Edward
>
> >
>

[Edward K. Ream]

On Wed, Sep 10, 2008 at 12:05 PM, Kent Tenney <kte...@gmail.com> wrote:

> Such enthusiasm!

I'm not enthusiastic about inventing arcane rules.

> Personally, I'd like to see another config file available via -c on
> the command line: (a common idiom)

I like this for several reasons: it gives you what you want and it
cuts across the recent haggling.

It's a perfect example of the maxim, "explicit is better than
implicit". There is no need to remember anything except -c, and there
is no need to convince me to change the already way-too-complex rules
for dragging in settings.

I'll put it on the list for Leo 4.5.2.

Edward