On Fri, Feb 27, 2009 at 9:00 AM, Edward K. Ream <[email protected]> wrote:
> >> Would there be value in assuming no sentinels and asking >> "What feature set is possible?" > > > That gives us @auto. We are stuck. > Many thanks to all who have contributed ideas today. It's great to see the creative juices flowing freely. Let me give here a general reply. Let us make a new distinction: **collaborative** @<file> types vs. non-collaborative @<file> types. @thin, @file and @auto are the only collaborative @file types. Leo can update these trees base on (massive) changes made non-locally, say via bzr. @shadow is *not* a collaborative @<file> type, so it can not be made the basis of any unified @file scheme. Ironically, @shadow now seems almost useless. The only reason that comes to mind for using @shadow is to be able to publish source code without sentinels. But Leo already has a remove-sentinels command. Of the three collaborative @<file> types, only @auto avoids sentinels. So in many situations, @auto is the only choice. At present, there are several *significant* problems with @auto: 1. @auto does not handle clones well. 2. @auto does not allow organizer nodes. 3. @auto does not allow customizable headlines. 4. @auto does not recreate section references when reading a file, although they can be used when writing @auto files. Now is the time to design a solution to these problems. This has much higher priority than fixing problems with @shadow. As mentioned earlier, in a collaborative environment the external file must determine structure **all by itself**. Ditto for content! Thus, the only way forward will involve adding information to external files. This information must take the form of lightweight sentinels, say *...@auto hints**. There is precedent for such an approach: Emacs outline mode uses something similar. Each node would be preceded by a single hint: #...@node:<gnx>: <headline> That's *all*. In particular, **indentation of the hint determines outline structure.** A directive (or setting) could be used to suppress these hints. Like this: + @nohints + @auto x + @auto y + @auto z All comments welcome. Edward P.S. Supporting section references in @auto trees would require additional hints. I doubt that the payoff is worthwhile. To have any chance of widespread adoption, hints must be kept to the bare minimum. P.P.S. I don't remember whether <v> element for @auto nodes presently contains any hidden machinery. I suspect not. But there is no reason, in principle, why such <v> elements could not hold non-essential data such as marks and expansion state, just as is done for @thin files. 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 -~----------~----~----~----~------~----~------~--~---
