As the history of Leo page shows, I have declared Leo to be "complete" once or twice before, only to have fundamentally significant improvements show up.
At present, Leo does more than I ever dreamed possible, and Terry continues to improve and generalize Leo's user interface. This state of affairs, somewhat ironically, seems to have the effect of inviting me to imaging even more fundamental improvements to Leo. Several ideas have been swirling around in the old bean lately: 1. I have recently been reminded of how cool the SmallTalk environment is. 2. Thinking about lint and program analysis leads me to think of Leo as a platform for new kinds of programming tools. 3. Terry's bookmark plugin, and the eternal problems with sentinels, leads me to think of ways of doing more with @auto and less with clones. Project files ========= I have been reluctant to work on a new file format because a re- visioning of what a .leo file is might be in order. Following SmallTalk, and other IDEs, it might be fruitful to think of a .leo file as a more traditional project file. To make this work, however, we must avoid bzr conflicts in such files, or make the .leo file an almost-never-changing file. Perhaps "plain" helper files, associated with the .leo file, could be part of the picture. Clones ====== Sometime in the last few months the distinction between "implementation" and "external/user" clones arose. Leo's internal data structures (vnodes) and the associated code **will never change**. The question is, however, whether there is some alternative to clones for the user, and consequently, some way to make @auto do more. The essence of clones is that they have a unique, immutable *identity*. This is a rare thing: it is much more common for things to have a *description*, which may or may not be immutable, and which often is not unique. Because of clone's identity, references to clones can never break. However, references can *disappear* because they are never saved. This is why clones do not survive in @auto files: Leo does not (can not) save the gnx's. To repeat: while we might want to de-emphasize clones in *some* situations, clones and gnx's will always remain an essential part of Leo. This will ensure that Leo will retain its important data- organizing properties. 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.
