On Mon, Apr 30, 2018 at 8:32 AM, Terry Brown <[email protected]> wrote:
Clones are really expensive. > > Expensive in the Python 2/3 transition and string/bytes/unicode > transition sense. They're always demanding extra dev. effort. > I'm glad you raised this question. It seems we are having a virtual design sprint. We are discussing the biggest questions of all. Answering these questions is part of my legacy. The time I spend on them will be the most important work I do this week. *Why clones are essential* One way to blight the future of Leo would be to eliminate clones. Don't go there. 1. Clones turn Leo into a true data base. My brother speed uses clones for this purpose, as do others. The Nav pane can not replace this use of clones. 2. The clones created by the clone-find commands are available for *other* searches. This is not possible with the Nav pane. 3. Some people, myself included, strongly prefer using clones. 4. As you say, clones can be used for templating or in languages like html that lack any other structuring mechanism. Clones generate the need for @fil > e > . > > Ok, not really true and way overstated Correct, it's not true. And it's not just overstated. The need for @file arises from true outline nodes, not clones. Eliminating sentinel would *complicate *some code significantly. gnx's are so useful. For example, the goto-line-number commands requires sentinel lines, *even for @clean trees*. The code uses "virtual" sentinels from the outline itself. That was the Aha behind @clean. *Leo's code is already good enough* The Position and VNode classes are solid *right now*. Once in a great while a bug crops up in these classes. Local fixes have always sufficed in the past, and I expect that to remain true forever. In fact, clones impose much less of a maintenance burden than does the python 2/3 split. I am quite certain that the Position and VNode classes can not be simplified in any meaningful way. Getting rid of clones would be a huge project that could break Leo's code in a myriad of ways. It's fine to consider doing so as long as you ultimately reject this idea ;-) Yes, there is some ugly code in Leo, but I have just fixed the worst code of all, the key-handling code. To my knowledge, *all* the remaining ugly code is confined to one ugly method and its ugly helpers, that is, a node and its descendants. Yes, there is ugly code that reads .leo files (leoFileCommands.py) and external files (leoAtFile.py). But the code, while ugly, does not truly suffer from an exponential rise in complexity. Clone-related code typically increase the paths through methods from 1 to 2 :-) Even when there are N kwargs, there is actually only 1 path through the code, with N minor "detours". *Priorities* Here are the priorities (in order of importance) that I recommend for you, Terry, in your future role as project manager: 1. [Highest] Keep users happy. Don't break their scripts if you can possibly help it. Don't even think about taking features away from them. 2. Keep your devs happy. Listen to them. Change your mind occasionally. 3. Focus on design, not code. Will new code add something special that is only possible with Leo? 4. Fix bugs as they arise. 5. [Lowest] Clean code as the opportunity/inspiration arises. Simplifying code isn't likely to rock Leo's world. *Summary* Major changes to Leo's code base are not necessary, and threaten to divert attention from much more important work. Localized changes are often desirable. It would be a huge mistake to (try to) eliminate clones. We might spend weeks or months on the project only to discover that we have just created dozens of new bugs. The Nav pane cannot fully replace clones. Clones are the foundation of Leo as a DB. Besides, deprecating clones would alienate many users. It is rare that we get to discuss these crucial questions. I'm glad we are doing so now. 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.
