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...
+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
On Aug 16, 8: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 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...
On Sat, 16 Aug 2008 10:14:07 -0700 (PDT) "Edward K. Ream" <edream...@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.
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.
> 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.
Which would suggest that .leo_shadow should be .leo/shadow...
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 Bienstman <Peter.Bienst...@ugent.be> 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.
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
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.
<Peter.Bienst...@ugent.be> 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.
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.
On Sun, Aug 17, 2008 at 4:01 PM, Randy Kramer <rhkra...@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
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.
On Wed, 20 Aug 2008 07:46:41 -0700 (PDT) "Edward K. Ream" <edream...@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.
On Wed, Aug 20, 2008 at 10:10 AM, Terry Brown <terry_n_br...@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.
On Wed, Aug 20, 2008 at 10:10 AM, Terry Brown <terry_n_br...@yahoo.com> wrote:
> On Wed, 20 Aug 2008 07:46:41 -0700 (PDT) > "Edward K. Ream" <edream...@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.
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
On Wed, Aug 20, 2008 at 11:36 AM, Kent Tenney <kten...@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
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, Randy Kramer -- "I didn't have time to write a short letter, so I created a video instead."--with apologies to Cicero, et.al.
On Wed, Aug 20, 2008 at 7:15 PM, Randy Kramer <rhkra...@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.
On Thu, Aug 21, 2008 at 2:32 PM, Edward K. Ream <edream...@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.
-- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
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!
regards, Randy Kramer -- "I didn't have time to write a short letter, so I created a video instead."--with apologies to Cicero, et.al.
On Wed, Aug 20, 2008 at 1:09 PM, Edward K. Ream <edream...@gmail.com> wrote:
> On Wed, Aug 20, 2008 at 11:36 AM, Kent Tenney <kten...@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 :-)
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.
On Thursday 21 August 2008 08:20 am, Ville M. Vainio wrote:
> On Thu, Aug 21, 2008 at 2:32 PM, Edward K. Ream <edream...@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. ;-)
Randy Kramer -- "I didn't have time to write a short letter, so I created a video instead."--with apologies to Cicero, et.al.
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.
|
