On Sat, Apr 28, 2018 at 6:46 AM, vitalije <[email protected]> wrote:
> O.k. No more complains from me.
>
Well, I hope you mean, no more complaints about the VNode class ;-)
Please do continue to question Leo's design, code and style, or anything
else. The last thing I want is to stifle discussion and debate.
My brother (a very fine programmer) and I have a running joke. We ask,
"Who wrote this ***? Oh yeah, I did". Every time we look at our code with
fresh eyes we see something that could be improved.
Thinking back about my reply, I worry that all the italics and boldface
might be misunderstood.
I was not at all upset about your criticisms and questions. I was trying to
emphasize what I think are truly important ideas underlying Leo's
architecture. These ideas exist explicitly nowhere in the code itself! So
I welcome any chance to explain them more fully.
Indeed, I want to say at least a few more things about Leo's architecture.
The fundamental principle could be restated as follows:
*Modules and classes should never know about the inner workings of other
classes*
Just now I see that this isn't as simple an idea as I thought.
Usually, knowing about the *existence* of methods of other classes is
benign. But calling *low-level* methods of other classes would be asking
for trouble. But what is a low-level method?
The outline for the VNode class has an organizer node for its low-level
methods. Furthermore, all low-level methods of the VNode class have names
starting with underscore. So, for the VNode class, we know for sure which
are the low-level methods.
But for other classes, that might not be so obvious. Leo's code doesn't
follow the underscore convention consistently. I often use the "Helper"
suffix instead.
I think it's safe to use methods that correspond directly to user-level
commands, but that's only a partial guide...
Turning from methods to ivars, the rule is:
*Code should use only official ivars from other classes*
Alas, it may not be obvious which are the official ivars.
"@test official g.app ivars" defines the official ivars of one class.
Other classes have comments about what their official ivars are.
CheatSheet.leo contains lists of the important ivars, so I guess the
concept of official ivar isn't too mysterious. In any case, code like:
c.frame.body.wrapper
should be fairly easy to understand. But I look at the code every day...
*Dubious design and code*
This is a good time to discuss truly dubious aspects of Leo's code base.
1. The identification of c (and the Commands class) with a single outline
*on the screen.*
The code assumes that "c" means outline. There is no easy way have two
separate outline views of the same file. This greatly complicates all code
involved in switching between body editors.
This design choice can't change, but I would think about this more
carefully were I to design Leo from scratch.
There have been proposals to handle multiply-selected outline nodes. That
can be indeed be done in a fairly straightforward way, *provided that* any
new commands don't attempt to generalize what c.p means.
2. LeoTree.select is horribly complex.
This code handles all the details of switching between nodes. It can be
called as the result of user actions or as the result of commands. It's
likely that all the complexity is inherent, and I wouldn't recommend
changing it, but it's still horrible ;-)
3. The key-handling code is still too complex.
The new code is a huge improvement, but problems remain. As yesterday's
bugs show, ks.isPlainKey must be exactly right or embarrassing bugs will
result.
I have just added this line to the docstring:
A plain key is a key that can be inserted into text.
Clearly, the code must eventually make this distinction. It can't treat
'\b' like any other character.
The helpers of k.masterKeyHandler disgust me every time I look at them.
They are a maze of code that just barely manages to work. There are reasons
why the code is as it is, but still...
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.
