Creating better tutorial videos for newcomers has top priority, but when a rush of thoughts comes on it's useless to ignore them.
The recent vivid dream probably presaged these thoughts. ===== Sentinels & @shadow The fundamental problem with sentinel comments in external files is *not* primarily that people using other editors dislike them. That's merely a fatal problem ;-) Rather, the fundamental problems with sentinels are:: - Outline structure (including headlines) is real data and - Leo Users want to share that data. At last I see why I have never (deep down) thought that @shadow is good enough. Yes, it's brilliant technology, but it does *not* allow two Leo users to communicate the outline structure each uses. Instead, @shadow allows each user to "patch in" changes made by other people, while retaining their *own* notion of the outline structure. This mode of operation is, fundamentally, not good enough. It is merely a hack to allow Leo users to coexist in "hostile" (non-Leo) environments. To put it another way, there is presently no way (using just @shadow) that Leonard and Linda (two Leo users) can change outline structure and have the other person see those *structural* changes. With @shadow, each user ends up shoe-horning the other person's changes into their *own* outline structure. Intuitively, there must be situations where this not be good, no matter how much smarts @shadow is given. ===== Diffs & syncing If outline data is to be real, sharable data, it simply cannot be "reconstituted". It must be *transmitted*. Sentinels are the simplest, safest, way to transmit that data, but we all know that sentinels are verboten in many environments. With present file systems, this means transmitting the data in one or more real, separate, external files. Naturally, this creates many complications. The *fundamental* complication is that we can *never* guarantee that structure data and non-structure data are in sync. The proof is immediate: structure data comes only from Leo. If Nancy (not a Leo user) changes an external file, she will not update the structure data, no matter how much she does, in fact, change the structure of the data! In this case, @shadow, imperfect as it is, will be the *only* way for Leonard and Linda to update their own view of the data. Too bad, so sad. Otoh, if either Leonard or Linda change the data, we want to clear, foolproof way for them to communicate *all* the changes (including structural changes) to the other. The idea I have is this. Leo could create a **diff file** containing the (text diffs) applied since some "checkpoint". A bzr/git commit seems like the obvious candidate for such a checkpoint. For each changed file, the diff file would contain a sha1 hash of the before and after versions of the file, as well as a diff (or patch?) Perhaps only a single diff file is needed for each checkpoint. So that's about. As I write this, I am not particularly pleased with the result. The problem is that Leonard and Linda are *always* going to be forced to fall back on the @shadow algorithm to incorporate changes made by Nancy. They have no choice. The diff file doesn't exist because Nancy didn't create it. (In effect, the @shadow algorithm reconstitutes the diff file.) Boo hoo. @shadow is now provably inadequate to handle arbitrarily large reorganizations of source files, and at the same time, @shadow is now provably necessary to deal with non-Leo users. We seem to be completely stuck... Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
