This is an Engineering Notebook post. It consists of concise/cryptic notes to myself.
*Design* I wasn't expecting so many ideas so quickly. Shows what getting rid of distractions can do. Typically, we devs are rightly concerned with fixing bugs, adding smallish new features, improving performance, and fighting the dreaded software rot. So it's important to completely change focus from time to time. *Scripts, predicates, patterns, graphs* These are the most general tools at our disposal. Patterns and predicates (to the clone find commands) are special forms of general Leonine scripts. Leo's main data structure is a DAG, but the backlink.py plugin allows arbitrary links between nodes. We could also define *implicit links* using new directives, say using @tag or even maybe @backlink. These ideas may apply to #1482 <https://github.com/leo-editor/leo-editor/issues/1482>, #1035 <https://github.com/leo-editor/leo-editor/issues/1035>. *Key Handling* I don't care much about improving Leo's key-handling features. The "keystroke competition" between vim and emacs <https://www.youtube.com/watch?v=dE2haYu0co8> strikes me as small-minded and uninteresting. Improved key handling can not possibly lead to new ways of using Leo. That said, Leo's key handling code could be made cleaner and faster, per #1269 <https://github.com/leo-editor/leo-editor/issues/1269>, which I have just reopened. The Aha: the script that ensures that the old and new ways are equivalent would be the basis of the new code. *Leonine graphs* Imo, most graphs purporting to summarize programs are useless. Instead, Leo outlines *themselves* could be considered graphs. We can imagine new *derived graphs* as abstractions or projections of existing graphs. Leo can easily embed such new views into the outlines themselves. At present, the clone-find commands use predicates to select *entire nodes*. Instead, predicates could select text (by text pattern, or tag), and create *new* nodes. Such predicates might show the way towards #946 <https://github.com/leo-editor/leo-editor/issues/946>. *Databases* db queries are special forms of scripts/predicates. Aha: instead of mapping an entire db to a Leo file, we can use db queries to create much smaller data sets (outlines) within Leo. We then have all of Leo's tools at our disposal. When done, a script can update the db from the outline. This is a big deal. A simple change in point of view eliminates/reduces the burden of handling huge db's. Instantly, we can imagine Leo accessing selected data from the human genome project, or any other big data. *Summary* Focusing on design naturally leads me to consider scripts, predicates, patterns, graphs, and DB queries. These are Leo's fundamental assets, augmented by Leo's api. Galois Groups <https://en.wikipedia.org/wiki/Galois_group> are a more abstract view of a field <https://en.wikipedia.org/wiki/Field_(mathematics)>. Galois groups form the basis of a spectacular theorem about polynomials <https://en.wikipedia.org/wiki/Abel%E2%80%93Ruffini_theorem>. Similarly, we want to look for Leonine outlines that provide "better" views of documentation, databases, programs, and possibly other kinds of data. Such "summary outlines" are not just pretty pictures, they are the basis of further computation. 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/8f7e52a5-e5f4-4c05-92c4-f5fb8dc98250%40googlegroups.com.
