On Fri, Apr 27, 2018 at 7:04 AM, vitalije <[email protected]> wrote:
Why is it important to allow user to paste outline in another editor? > Ok, I'll concede that it's not too important. > To make the discussion easier I will name this > [dubious] > design principle "flexibility no matter what" (FNMW). > I don't have this as a conscious design principle. Leo's commands are modeled after Emacs commands. The key principle is: ignore the commands that don't interest you. > The same logic should be applied to code design. If you need to achieve > some flexibility in a certain part of code, then no effort should be spared > to implement it. But if there is no evidence that the flexibility would be > used, usually it will make code shorter, cleaner, easier to understand and > maintain, and often faster to execute if you forget about that flexibility > and make smallest viable product. Keep the energy for more important things. > I agree. But none of Leo's kwargs have *ever* been added for *theoretical *flexibility. They have always been added to satisfy a practical need. Later, it sometimes happens that the need for a kwarg disappears and the kwarg becomes "vestigial". Now that we have the clone-find commands, vestigial kwargs can (should!) be removed. > I can point out to many examples of this > > FNMW design principle throughout the Leo code. Many modules, classes, > methods and functions are designed as if they were public libraries used by > many users for different use cases. But most of those modules are used only > by Leo developers and in a very specific way. Those modules could be made > much more readable, smaller, more efficient if they were tailored to a more > specific task they need to perform and not as a general purpose tool that > can be used for many other tasks. > Really? What modules, classes, methods and functions trouble you? The actual design principle that I consciously follow *all the time* is that modules and classes should hide all details about an easily understood *idea.* In other words, Leo's design is about making modules and classes completely independent from each other. That's what makes Leo stable. To the first approximation, nothing else matters, and certainly not details about kwargs. > Without any intention to diminish any effort that recently went into > making very flexible theme handling code, I still wander whether it was > good thing to do. Let me explain a bit. I haven't looked at that code yet, > and I have only skimmed through the theme related discussion. So, I may be > very wrong about this. > I think Terry and I would agree that you are, indeed, mistaken. The present system didn't happen as a result of some imagined design principle. It happened because stylesheets are built into Qt. Yes, the code is complex, but it's complex for good reasons. In particular, it must coexist with Leo's configuration code. I just can't imagine that lots of users will see or use this flexibility. > The new theming code hides most of this complexity, but we can't just require that everybody throw out their existing myLeoSettings.leo files. We have to support more complicated ways indefinitely. > Basically qt stylesheets are just plain text files and Leo had already > large number of tools for writing text files. Was it really the case that > those stylesheets couldn't have been written using only standard Leo > features for dealing with external files? > If we could travel back in time, the answer might be "no". But now the answer is "yes". > Another example: unknownAttributes. In other thread we were seriously > discussing possibilities that some user may have some exotic data in uA and > what should we do to make this feature most flexible. But where is the > evidence that any user would actually use that flexibility? > Leo is a programming environment. In principle, we don't know how people have *already used* uA's. No way am I going to change uA's without an exceedingly strong reason for doing so. > I don't recall that I have ever used uA for any purpose. > It doesn't matter what you or I have done with uA's. They are a fundamental part of Leo and they aren't going away. > "The perfection is achieved not when there is nothing more to be added, > but when there is nothing to be removed." > This is a great design principle. I use it all the time. > we risk that one day Leo would support so many features that no-one would > be able to remember or use just one tenth of them and Leo code complexity > would exceed the ability of mightiest human mind to understand. > We are already at that point. However, this didn't happen because of FNMW. It happened because Leo creates a new programming and data world, with almost limitless applications. Nobody, including Leo's core devs, uses all the potential features. But every single feature, without exception, exists because there was at least one user who made a strong case for it. > It is already very hard to understand some parts of Leo even with the help > of Leo's outlining capabilities. > > We could debate the degree to which this is true, but I don't see any way *in general* to mitigate this problem. But there is no reason to despair. For example, the recent keys-related work has significantly simplified what was (and still is) very complicated code. That complexity is inherent in: a) how Qt represents incoming key events and b) how bindings are represented in settings files. We can't change either a or b. But that has not prevented me from simplifying the code. > > It may be a good strategy to examine each Leo feature in terms of how > often it is used and if the same effect can be achieved through some other > features. > > Imo all of Leo's features deserve to remain. Some, like @root, are hidden, but they *must* remain indefinitely because people still use them. *Summary* My one and only "big" design principle is that modules and classes should hide all details concerning one "topic". This is Glenford Meyers's great insight. It has worked well for decades. Leo creates a new programming and data world, with almost limitless applications. That's what drives all of Leo's core code. *All* of Leo's features are the result of specific user requests. Changes to Leo's code base can be considered only if they do not greatly impact Leonine code* of which we have no knowledge*. This includes uA's. We devs have no choice but to live with the complexity of Leo's code, reducing that complexity incrementally when we can. We must not sacrifice features *merely* to make Leo's code base simpler. 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.
