Recent criticisms of Leo and its architecture have been wildly off the mark. The most ludicrous was the statement that 'c', 'g' and 'p' should have longer names.
Here, I'd like to discuss Leo's *real *weaknesses. Some have recently been exposed as I study pyzo's operation and code. I'll also explain how they arose and what might be done about them. With one exception, these have nothing whatever to do with Leo's classes or code. *Collaboration difficulties* Imo, this is Leo's main weakness in the world. It's not all that easy to share .leo files. Diffs don't work well with xml files. Converting from xml to (say) json, won't help. Jupyter is far superior in this regard. The Jupyter project has had to handle the usual security considerations. It appears that they have come to a reasonable approach. This is one reason why the "Jupyter in Leo" project seems important to me. *Weak or missing basic editor features* Pyzo shows just how much Leo's syntax coloring, code completion and debugging capabilities could be improved. I intend to remedy these defects this year, basing my work on pyzo's brilliantly simple code. *Dubious decisions* Most of these happened long ago, for what seemed like good reasons at the time. 1. *Using wrapper classes for text editing* The present Qt gui is, iirc, Leo's fourth gui. Two preceded Leo in python. Previously, the python version of Leo used the much weaker Tk gui. The pyzo code shows just how big a price Leo has paid for the wrapper text abstraction layer. Otoh, having a standard text widget greatly simplifies the curses gui plugin. Still, the text wrappers do complicate matters significantly. 2. *Commands are defined in the Commands class* This class really should be called the Controller class, using MVC <https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller>terminology. Anyway, defining defining commands in the c class made sense initially. Commands are clearly not parts of Leo's (data) model, nor are they part of a view. If I were to do things all over again, I would likely split 'c' into 'c' and 'c.commands' components. But that's not possible now because it would break existing code. In my defense, the original (python) design happened long before Python had decorators. In fact, it's not even possible to split leoCommands.py into separate modules. I've actually tried (twice) and given up quickly. Mistakes would break Leo and there aren't nearly enough unit tests to catch those mistakes. 3. *Underestimating regular expressions* Almost all of the g.skip or g.scan functions could be replaced by regular expressions. That would greatly simplify the code. I haven't done this because there are bigger fish to fry. The g.skip or g.scan functions could also be rewritten *using* regular expressions. But this *must* be done safely. I will reject any pull requests that do not contain strong unit tests that demonstrate *complete *compatibility with previous versions. *Outlines and clones complicate everything behind the scenes* This is unavoidable. It's not a mistake and it's not the result of bad design or poor programming. The flip side is that leo can do things no other IDE can do. But this *is* still a weakness of Leo. Leo's code can be complicated. For example, supporting an in-Leo debugger requires Leo's goto-line-number code. No big deal: that code is encapsulated. But there remain off-by-one errors that have to be fixed. So that's it. I've confessed to you all of Leo's real weaknesses, as I see them. Leo's behind-the-scenes complications do impact day-to-day work. Otoh, this "weakness" makes all of Leo's unique features possible. But a balanced view would also mention Leo's successes. The main design success is that it is *always *possible to revise the internals of any class without major effects outside those classes. For example, I'll be able to revise leoColorizer.py so it uses the brilliant pyzo syntax coloring code without having to worry about global impacts. Finally, I'd like to say a few words about the supposed "haphazard" nature of software design. Imo, such complaints are akin to complaining that a novelist's characters seem to have a life of their own. In fact, Leo's classes are driven by the tasks to be done. New classes arise as new task arise. This is a completely natural process. Leo's design means that new classes do not break old classes. 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
