> 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
Cheers -Terry
Which would suggest that .leo_shadow should be .leo/shadow...
> Cheers -Terry
>
> >
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
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'
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.
I think we have enough good ideas for now :-)
Edward
> 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
Just for the record ;-)
The configuration problem happened on Linux: replacing a link.
Edward
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
>
> >
>
> 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
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,
>> 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
> 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.
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!
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
>
> >
>
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. ;-)
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
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
:-]
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
>
> >
>
> 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
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
>
> >
>
> 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
> 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
All right. Is there anything except documentation that should change?
Edward
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
>
> >
>
> 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