On Mon, Aug 2, 2010 at 7:55 AM, Edward K. Ream <[email protected]> wrote: > I am beginning to feel that something basic is missing from Leo.
I am having thoughts about Leo that I have never had before. That's exciting in itself. 1. One set of thoughts involves re-imagining what a .leo file is. For example, instead of leoPyRef.leo and leoPy.leo, suppose we have leoPy.leo be the "official", changed-only-when-a-new-file-is-added-to-the-project "view" of the project. I want bzr to backup all my development work, so I want an ekr_leoPy.leo (and ekr_clones, see point 2) as the vehicle to do that. People would be free to see my view of the data, but I would request that people not change either leoPy.leo or ekr_leoPy.leo. Instead, people would create, say, ville_leoPy.leo or kent_leoPy.leo, and if desired, add those .leo files the the bzr repository. In the unlikely event that Ville wants to see my view of leoPy.leo, he can open ekr_leoPy.leo. 2. This is just one example of a new distinction: local/personal vs. global data (or .leo files). To continue, ekr_leoPy.leo would use something like ekr_clones.txt to contain what is now in leoProjects.txt and leoNotes.txt, etc. This should eliminate conflicts in ekr_clones.txt--I do not expect to share ekr_clones.txt data even though it would be backed up in the bzr repository. So now the bzr repository has *two* uses: sharing (global) data and backing up (personal) data. It's a useful distinction, imo. 3. This suggests the following question: what if clones are primarily a local (personal, not often shared) kind of data? Again, this is a new *thought*. It might lead somewhere, or not. There is one exception that immediately arises: clones stand in for methods in languages like html. They are not simply part of a view of data: they are an essential part of the html file. I don't think this Aside: gnx's are required in thin external files no matter what. In spite of saying that sentinels are not the problem, I keep thinking that gnx's might be removed in some cases. But that's simply wrong! Perhaps personal my_clones.txt files are all that is needed to reduce the present clone-based conflicts. I think these files would be useful in the repository. 4. The question still remains: what to do about LeoDocs.leo? I agree with Ville that we must use thin external files to hold most of the data that presently is contained in the .leo file. It may be that something new is required, but more likely the present mechanisms suffice. I'll look into this asap. In short, there are two largely separate issues: the leoPyRef.leo question and the LeoDocs.leo question. Edward P.S. I plan to revisit caching asap. It may be that there are gaps in the present scheme that are causing confusion. For sure I want to verify that caching is reliable in all cases. EKR -- 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.
