Hi, I think that the main issue is that Leo is a vast system to explore, but it provides us with a unified metaphor to traverse it: the outline. This means that the system can increase complexity, but you can keep the same strategies to navigate such complexity. Something similar happens in the Pharo/Smalltalk world, with the class browser. Infrastructure gets more complex, to deal with more complex problems, but your strategies to browse such complexity are almost the same.
The issue is discoverability: how we find the stuff we need? In Pharo's case we have spotter (see demos at [1]), which are kind of a quick launcher/searcher for all functionality inside Pharo or its packages. In that way, user is browsing the system without manually going to a particular place by hand. Could something similar be implemented for Leo trees that works not only for the currently opened tree, but for the ones core or extra defining functionality? [1] http://www.humane-assessment.com/blog/short-spotter-demos/ This goes in line with the uses of Leo. I, as many was a long time user of Leo with a glimpse of how it unifies diversity with the ability to import/export external files in a unified metaphor (the Leo tree) and use clones and chunking to (re)construct them in arbitrary ways. But programming was difficult, mostly because I have not found, at the beginning a case where I need to program Leo from Leo (my use was to create external python scripts) and once I found it (Markdown export) Leo makes click. If discoverability is an issue, interactivity and community can be a solution. The later by being a place where to ask questions and to make some demos available to the wider community, and the former, by providing ways in which the software can be used to teach itself to the user. I think that Pharo/Smalltalk has a long tradition on that front and now Jupyter is making interactivity a first class citizen of the Python experience (something similar is happening with Observable in the Javascript world). It has been a long dream of mine to add interactivity to Leo, but as I said I'm now away of the Python world. But hopefully someone in this community could feel that necessity too and use interactivity to improve the ways we learn and explore Leo. Cheers, Offray On 30/1/19 8:54, Edward K. Ream wrote: > A recent question about g.getScript got me thinking... > > The OP was asking for information that I couldn't possibly know, but > is trivial to discover. > > First, you find the node that defines g.getScript in leoPy.leo, aka > leoPyRef.leo. The "trick" if you can even call it that, is to *look at > the child nodes.* This will show you the subsidiary tasks. > > In this case, there is a helper called g.extractExecutableString, > which has a "language" kwarg, so surely weirdness involving language > must involve this method. I have just created #1071 > <https://github.com/leo-editor/leo-editor/issues/1071> for this bug. > > When I awoke this morning I realized that many Leonistas might not > understand the first and most important Aha's about Leo and literate > programming. This is documented here > <http://leoeditor.com/history.html#apple-and-yellowbox>, in the > History of Leo <http://leoeditor.com/history.html>: > > "Late in 1997 I wrote a Print command to typeset an outline. Printing > (Weaving) is supposedly a key feature of literate programming. Imagine > my surprise when I realized that such a “beautiful” program listing > was almost unintelligible; all the structure inherent in the outline > was lost! I saw clearly that typesetting, no matter how well done, is > no substitute for explicit structure." > > As I reread this, I see that this quote obscures the main idea: > > * Outline structure tells programmers almost everything they need > to know.* > > This is a general principle! For example, I could try to document all > of Leo's important classes, but why bother? leoPy.leo contains all of > Leo's core classes, organized. It's easy to skim through the outline > looking for files and their classes. Once you find the relevant file, > you can expand its outline to see the file's components. You continue > the process until you find what you are looking for. > > It's really that simple. This is what I /always/ do when answering a > question. > > *Summary* > > More than 20 years ago I saw that Leo's outline structure reveals > almost all the relationships needed to understand any file, class or > method. Fancy documentation adds almost nothing. > > Every Leonine programmer should know and use this crucial Aha. > > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/leo-editor. > For more options, visit https://groups.google.com/d/optout. -- 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.
