Happy to help, though I'd say that less credit is due for stimulating thought than for thinking the thoughts! :)
Regarding the output of org-mode's exporters being similar to @nosent files, well, that's a feature. :) Export isn't "save". Moreover the exporter framework isn't generally used for emitting source code... You export html, PDF, OpenOffice, etc. For emitting source code, you'd use org-babel. That framework allows you to write snippets of source code in arbitrary programming languages into an org file and then execute each snippet individually, saving the output to the org file, or to external files. You can also write all the snippets into a single source file... Some crazy folk use snippets to write OTHER snippets or whole org files, causing the snake to eat its own tail. (Would you describe this as Leonine?) Sounds like sentinels allow you to emit a source file from Leo, change the source file, and then construct a new Leo file which, if you emit source again, would produce the *edited* file. Neat. Let me guess, sentinels live inside comments.. :) Is this system aware of the AST of some languages? Cheers, and thanks for the warm words, --Dave On Tuesday, November 26, 2013 3:45:19 AM UTC-6, Edward K. Ream wrote: > > 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.
