Over the years, Leo has acquired a number of tools that have the potential to influence its design. Caching using sha-1 keys is only the latest example. Other notable tools include @shadow and @auto.
Naturally, whenever a new tool appears, I begin a review process to see how it might affect ongoing problems. Really, though, there is only one problem: how to eliminate sentinels. Solve that and Leo takes over the world :-) Yesterday I took a long bicycle ride, and mulled over this problem as I took rest breaks. I reached a surprising conclusion. I won't attempt a detailed discussion of my train of thought. That's almost always impossible. But I did ask myself: what am I really trying to do? What do I really want? The answer is fairly simple: I want to make it possible for users to share Leo's outline structure, as well as the data contained in that outlines. I then invented the usual (for me) complex and sorta clever ways of sharing outline structure while using files that do *not* contain sentinels. You can think of all these methods as variations of @shadow logic. But then I had a new thought: thin files (external files corresponding to @thin nodes) *already are* the best possible way of sharing outline structure: - They are complete. They fully specify all aspects of the outline and its contents. - They are simple, robust and safe. In particular, they are "transmission friendly". There is no possibility that they can get out- of-synch with themselves. - They are "cache friendly". There is only one file to be cached, so there are no synchronization issues. - They are "compiler friendly". That is, thin files are valid .py files, valid .html files, etc. In essence, the Aha is the distinction between data and the views of the data. *As data*, thin files are *already* optimal. The mantra is: it's really stupid to try to improve something that is already optimal :-) The perennial objection to thin files is that they contain sentinels. But this is not, in essence, a complaint that Leo corrupts data in any way. Adding comments to a source file does not change its meaning! The complaint is, in essence, that people don't like how thin files *look*. This suggests a new approach. The way to "take over the world" is to provide *viewers* for tools such as emacs, eclipse, even bzr or git. Consider emacs. One could imagine Leo viewers for emacs that would show thin Leo files in various ways: - Raw: how Emacs would typically show any file, complete with sentinels. - Outline: how Leo would show a thin file: as an outline and body text. - Cleaned: a plain text view of the file without sentinels. This last view could use the @shadow algorithm to recreate a new version of the thin file. Notice how the outline view of a thin file does not require any .leo file! Conclusions 1. Thin files are the best *data* format for external files. By comparison, dual-file approaches such as used by @shadow are more complex, less reliable, and less useful. Splitting files is bad engineering when sharing data. 2. @auto and @shadow are useful for those who can only share plain text. Neither allows the easy sharing of outline structure across a network. @auto precludes any user-generated outline structure. @shadow is irredeemably clumsy in a networked environment such as bzr. 3. Rather than trying to fix something that isn't broken, it makes much more sense to provide user-friendly views of thin data files. The new thinking boils to this. Leo *offers* the ability to embed outline structure in external files. Some people will decline that offer. They are stuck with @auto or @shadow. Thin files are optimal for those who want to share outline structure with others. In short: let's focus on improving the views of Leo's external files. Trying to improve their content is a fool's errand. All comments welcome. 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 -~----------~----~----~----~------~----~------~--~---
