The recent discussions got me thinking about object identities, clones and sentinels.
While doing pt exercises in the pool I think I may have solved the "master problem". (Usually I wait until I am in the shower for my Ahas...) Naturally, having been wrong (or frustrated) so many times before, I'm not completely confident that I have thought of everything, but here goes. This is a fairly long post, so let me tell you at the start where I want to go. It may be possible to combine all the best aspects of @thin, @auto and @shadow into a new @<file> type. It may eventually be called just @file, but here let us call it @file! (trailing exclamation point) to emphasize that it is a new kind of @<file> directive. The essential idea is this: when writing @file! trees, Leo will write a public file (without sentinels) and (usually) a private file containing sentinels, much as @shadow does now. The trick will be figuring out how to make this scheme work in various kinds of cooperative environments. Let us just assume that some (fairly straightforward) trick will make this work. We have entered the promised land: A. When reading an @file! node, Leo will use @auto import code if no private file exists. B. When saving an @file! node, Leo will write both the public and private files, unless we want @file! to do the work of @edit, in which case Leo will just write the public file. C. When reading an @file node, we must compare the modification dates of the public and private files to see whether just to use the private file (if it is newer) or to use the general @shadow update algorithm (comparing the public and private files) if the public file is newer. The above allows @file! to do the work of @auto, @thin and @shadow. Furthermore, there would be little or no need for @asis, @nosent, etc. It would also probably be straightforward to have @file! do the work of @edit. In short, @file! likely could do *everything*. BTW, note that @file! would eliminate most of the problems with rST embedded in @thin trees. We would pass the public file to sphinx or docutils. The public file would contain no sentinels, so they would cause no problems. (Yes, we might have to ensure a blank line at the end of each node.) To repeat, the above is simply a road map to the desired result. We still have the hard word to do. In the interest of completeness, I'll now present my thinking about as it was in the pool. Some details of the thought process have already been lost: this is the best I can do. I first considered breakable clone links. While not a preposterous idea, they would, in fact, create significant complications throughout Leo. Imo, they would likely lead to unavoidable special cases: nodes in @<file> nodes would like have to be "master" nodes, and clones outside @<file> nodes would likely be subsidiary nodes. Furthermore, because clones can contained cloned ancestors, the likelihood of data loss, or worse, data corruptions or confusion, becomes very real in the presence of broken clone links. One antidote would be to make clones in @<file> nodes first among equals, but such a distinction would ripple throughout Leo. So, once again, the conclusion was that object identity is important. We simply can not fake identity by using mutable data such as headline text. Something like gnx's is required. Then my attention returned, more in desperation than hope, to the question of sentinels. I believe I quickly realized that no amount of "simplification" of sentinels is likely ever going to work. Many people just will not tolerate sentinels. This leaves only @auto and @shadow as possible salvations. I don't recall how this came about, but the phrase "reverse @shadow" appeared. Let us recall the essential problem with @shadow in a collaborative environment, namely that public files do not contain sentinels, and so can not specify the structure used by ones collaborators. Here is the Aha: what if we commit the so-called *private* files when using @shadow? This is, in fact, equivalent to committing @thin files. This is indeed a reversal of @shadow work flow. We would typically update the *public* files based on changes to the private files. Actually, this is trivial: the @shadow update logic is not used, and we just read the @shadow tree as if it were an @thin tree. You can probably see some complications here, but let me skip ahead to what might be called the "real" Aha, namely that we can imagine three (or is it four?) ways of using bzr. 0. Don't use bzr at all. There is no cooperation. 1. A fully Leonine environment, such as leo-editor. All committers to the repository use Leo. 2. A fully non-Leonine environment. At most one committer uses Leo. 3. A mixed Leonine environment. More than one, but not all, committers use Leo. Let's examine each case separately. Case 0. No cooperation In this case, the user can use @thin or @shadow, so it doesn't much matter how @file! would work. Case 1: Everyone uses Leo. In this case, we do the *reverse* of how @shadow was originally intended to operate: we commit the *private* files containing the sentinels. Since everyone is using Leo, there is never any need to commit the so-called public files. We may want to put the private files in the same directories as the public files, for convenience in folder organization, but in principle it doesn't matter where the private files go. All that matters is that we commit the private files, not the public files. Case 2: At most one person uses Leo. This case is also straightforward. We commit the *public* files, not the private files. Since only one Leo users is committing, only that user needs to know the structure data in the private files. Of course, collaborators can (in effect) change outline structure without having the Leo outline, but that will be rare, and it will likely not be a serious issue. Case 3: Two or more people use Leo cooperatively, but some people do *not* use Leo. This is the hard case. Ideally, we would commit both the public and private files. Leo users want the private files; the non-Leo users want the public files. To make this scheme work, we would want a way to force users to commit public/private pairs of files in synch. This is possible in principle, but I'm not sure how easy it would be. In the worst case, Leo users could fall back on @auto, but we really would rather avoid that sad eventuality. BTW, it might be good for this case to put all files containing sentinels in a single place, so as not to overly pollute the directory structure in the repository. Conclusion It looks to me that cases 0, 1 and 2 would be easy to do. Case 3 is harder, but feasible. Unless I am horribly mistaken, @file! promises to relegate the (absolutely essential) sentinels to the background for almost all use cases. In effect, we get all the advantages of @thin nodes in all use cases. Leo's processing for @file! nodes would be fairly straightforward in concept. Interestingly, the behind-the-scenes atFile read.write logic uses just about every trick in Leo's book: @auto import code initially, dual writes of public and private files, and the standard @shadow update algorithm as needed. All comments welcome. It really would be nice if this general scheme could be made to work. 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 -~----------~----~----~----~------~----~------~--~---
