There has been intense work on Leo lately, (better search, vim mode, screencasts, etc) but none of it is, imo, sufficient to create a 5.0 version of Leo.
Otoh, Zoom.Quiet recently put his finger on Leo's Achilles' Heal: the difficulty of collaborating using Leo. Leo's sentinels are like the fundamental reason why Leo hasn't caught on. The recent friendly exchange between Dave Loyall and myself has brought this topic again to my mind. Sure, Emacs has a fanatical following. Ditto for vim (and Eclipse and the others). Sure, Leo has *looked* broken to casual observers because of the find panel, and perhaps for other reasons. But sentinels are the real reason why Leo *can't* catch on in big shops. @auto isn't good enough: it cuts the heart out of clones. In a previous thread, How to collaborate using Leo, https://groups.google.com/d/msg/leo-editor/jELB2In0gF8/V5obUxMETboJ, I discussed this idea: QQQ Suppose the "transmission line" (pushes and pulls) only carries files *with* sentinels. This ensures lossless transmission of data and sidesteps the intractable synchronization problem. The Leo project must provide *two kinds* of bzr hooks, one for Nancy (non-Leo user) and one for Leonard (Leo user) QQQ Although a cute idea, it probably won't work in practice because it imposes non-zero burdens on non-Leo users. Last evening I had several new thoughts, stimulated by Dave Loyall's recent post: 1. An org-mode outline is that analog of a .leo file, not one of Leo's external files. Indeed, Leo 5.0 should at least offer the option of having .leo files *be* org-mode files. Aside to Dave: this illustrates the problem with org mode: In effect, all external files produced by org mode are @nosent files! This just isn't anywhere near good enough. 2. For Leo to catch on, **sentinels must go**. The only way to do this if to use **@shadow everywhere**. And now for a cascade of new thoughts: 3. It is easy to test @shadow everywhere without changing @file to @shadow. Just create a new switch: @bool use_at_shadow_everywhere = True. So simple. So important. 4. @shadow presently uses an ad-hoc caching mechanism (specially named private files in .leo_shadow directories). But Leo already *has* a caching mechanism. Why not use it?!? This could speed up @shadow dramatically. It also offers opportunities for cross-file clones. Clones now become an intrinsic property of the "nearest" cache. In some sense, these caches define a "scope" in which clones have a unique identity. The fewer the caches; the wider the scope. It's a fertile idea. In other words, it may be desirable to "promote" caches into more general consciousness. 5. @shadow will always have trouble placing changed lines that lie near node boundaries: such lines could go either at the end of one node or the beginning of the next line. **Important**: theoretically, this choice does not matter, because the **result** (public file) will be the same regardless of this choices. This is the insight that Bernhard Mulder probably understood, but never mentioned before he died. I understood it only afterwards. But if we contemplate using @shadow for *all* files, then it does matter, in practice, whether @shadow can "guess" correctly. Last night I saw that I've been complacent about this. Simple rules of thumb, or even some almost-completely-hidden signals in the code, could allow @shadow to choose correctly. By "almost-completely-hidden" I mean the kind of convention that allows Leo to reconstitute whitespace properly in @doc parts. Perhaps a trailing blank on a line could mean something. Haha. (Whispers) I shouldn't tell anyone about this. They might start complaining about how Leo is ruining their sources! Even without such hidden data, @shadow could do some simple AI to guess correctly. For example, indented text preceding a Python def should likely be part of the previous node; text at the same indentation level of the def should likely be part of the node containing the def. Summary - Leo's sentinels are the biggest barrier to more widespread adoption of Leo. Not documentation. Not anything else. - @bool use_at_shadow_everywhere would allow us to test @shadow everywhere without changing .leo files. - @shadow could benefit by using Leo's existing caching mechanism. - Some (relatively simple!) way must be found to allow @shadow to guess correctly most of the time. This last point is the key, imo. Only testing will show how much further invention will be required. Thanks, Dave, for stimulating these thoughts. Oh Bernhard, I'm sorry I waited so long to see the true potential of your stroke of genius. 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.
