On Sat, May 8, 2010 at 12:57 PM, Ville M. Vainio <[email protected]> wrote:
> Plugins to existing frameworks die much faster than individual programs. Interesting point of view. I hadn't considered it. This remark might save a large amount of dead-end work. Otoh, there is also the possibility that a Leo plugin would be so useful that the vim/emacs/eclipse/mathematica people might want to make it part of the core, or support the plugin officially. > One problem with Leo's continued life after you retire is the complexity of > the code. For me, complexity manifests itself as difficulty making changes. That doesn't happen frequently, though leoConfig.py and leoKeys.py could be simplified. The "essence" of Leo resides in leoNodes.py, leoAtFile.py and leoFileCommands.py. leoNodes.py can't be simplified significantly: 10+ years of simplification has seen to that. The two file-oriented modules are a bit complex because there are so many variants, but these files are and have been remarkably stable. > The basic "essence" of Leo could be > crystallized in much less code than what is around currently (e.g. by > relying on text editor classes to do text editing, removing the ui > plugin compatibility layers etc. etc.). Eventually we'll want code > more people can understand inside-out so that you could consider > retiring with good conscience (knowing that Leo will continue to > evolve). I can't control what happens after I'm gone, but I think it would be a mistake to try to simplify Leo by robbing it of its present features. True, there is a lot command-oriented code, but leoEditCommands.py actually contains a lot of pretty simple commands. Furthermore, I consider the ability to alter Leo's outline, body and log panes from scripts to be quite important. We would lose that ability were we to rely on off-the-shelf editor components. I would not advise trying to do away with the text-widget wrappers: they provide a good boundary between Leo's core and the gui plugins. Although wrappers do add a layer of complexity, they do not, in fact, complicate the code that uses them. In short, I think most of Leo is about as simple as can be, and I plan to simplify the problem areas this year. To put it another way, the code isn't really that complex if one understands its organizing principles and why it must be they way it is. This big picture should be much easier to understand than the picky details. I often have to "relearn" the details as I fix code, but that is never a problem because I understand the big picture so well. Thus, the big payoff for you or any other potential maintainer is to see the big (simple!) picture as clearly as I do. Naturally, I am willing to do whatever it takes to make this happen. As I write this I see that perhaps all that I need do to make Leo live on is to have one or two key developers see the Leo's design as I see it, namely as something fundamentally simple. Were this to happen, and were there proper documentation explaining the simplicity, Leo might go on for a long time. 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.
