An avalanche of new thoughts

[Edward K. Ream]

Something totally unexpected happened today after reviewing the ancient 
items in leo/doc/leoToDo.txt.  I see new directions for Leo, and new ways 
to think about old issues.

*Background*

This particular avalanche was triggered by reading Kent's request for "node 
pipes".  I have just created #667 
 for this request. The 
actual trigger was realizing how badly I had misunderstood Kent's request.  
Kent made his request explicitly in terms of the demo at the bottom of Light 
Table's main page . Kent wasn't asking for a way to 
pipe data into p.b. That's trivial.  Instead, he was asking for a way to 
"inject" data into the gui itself.  For example, one might want to inject 
data into the body pane's *gui*, that is, c.frame.body.wrapper.  That's 
considerably harder.  And a whole lot niftier.

The "snow pack" of the avalanche consisted of lengthy discussions in 
leo/doc/leoToDo.txt.  In particular, Offray complains at length that 
software is way too hard to develop. Software is too sclerotic.

*Flexible vs sclerotic*

I asked myself: how can Light Table be so flexible?  My answer (perhaps 
bogus?) was that Light Table is based on html/javascript/css. As a result, 
Light Table, through the js DOM, has full access to the visual components.  
This shaky conclusion has had many interesting results.

I then asked myself, what parts of Leo are flexible, and which are 
sclerotic?

- *Flexible*: Leo's scripting API and related DOM.

Both are much better than good enough, and both are easily and fully 
extensible.

- *Flexible*: Leo's plugin mechanism.

Again, plugins are much better than just good enough, and plugins have 
unlimited flexibility.

- *Flexible*: Leo's abstract panes.

The console gui plugin drives Leo's tree, body and log panes without any 
interaction at all between Leo's commands and the actual body code.  That 
is, all of Leo's commands are insulated from the details of the particular 
gui in effect.

- *Sclerotic*: Leo's @shortcuts nodes mix all pane bindings together.

Instead, Leo could use @data -shortcut nodes that are inheritable.  
Like this:

   - @data text-shortcuts: definitions for *all *text widgets, unless 
overridden in children.
 - @body-shortcuts (overrides for the body pane)
 - @minibuffer-shortcuts

This would provide a way of defining *key tables* for each *individual *widget. 
 
This would greatly simplify Leo's internal processing.

- *Sclerotic*: Leo's concrete gui code.

Terry has made Leo's gui more flexible than it was, but Qt seems to be 
showing signs of age.  In contrast, web development continues to gain 
momentum.  Joe Orr's LeoVue project highlights what can be done with 
off-the-shelf web components. Imo, Leo is always going to be a desktop app, 
but I am thinking that Leo might use a browser as the graphics back end.

Leo could simulate the js DOM with a new Leonine API.  For example, it 
would be possible to simulate  getElementByName by searching through Leo's 
Qt widgets, using widget.parent(), widget.children() and widget.objectName()

- *Partially sclerotic*: Leo's rendering tools.

The rst3 command is flexible, but uses horribly complex code in the 
background.  Similarly remarks apply to the VR and VR2 plugins.  Perhaps we 
are suffering from vue.js envy. The soon-to-be-created new rendering 
enhancement requests suggest possible ways forward.

- *Partially sclerotic*: Leo's attribute handling.

The newly renamed #588 Make node attributes visible, with support in Leo's 
core  aims to make 
attributes more flexible *and* more visible. Along with type-related Leo 
directives, it might be good to make rendering-type "bits" visible in all 
headlines.

*Summary*

There is a lot to chew on here. The overall goal is render Leo's gui in the 
niftiest, most flexible manner possible. It may be that web/javascript 
tools will be the new path forward.

I will be creating about 30 new enhancement requests as time allows.  They 
may suggest new ways to make Leo more flexible.

All comments welcome.  Please try to avoid dissertations ;-)

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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Coming soon: about 30 new enhancements

[Edward K. Ream]

On Wednesday, January 31, 2018 at 7:14:17 AM UTC-6, Edward K. Ream wrote:

I'll be creating new issues today.
>

This may take awhile.  I plan to do considerable curating of each 
enhancement proposal. Several proposals deserve careful study.

Hmm. The title of this tread should say that I'll be creating enhancement 
issues. 

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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Coming soon: about 30 new enhancements

[Edward K. Ream]

Recent revs contain a major reorg of Leo's internal to-do list.  All items 
have been moved to one of three categories: move to issues, unlikely or 
won't do.  I'll be creating new issues today.

The "Unlikely" and "Won't do" categories will remain "forever".  They 
document ideas that I have rejected, for the reasons stated.

There are some gems in the new issues:

- Miles Fidelman, HansBKK and the late Bernhard Mulder propose tools for 
collaborative .leo files.  At least two of the proposals mention TiddlyWiki 
.

- Ville proposes using Travis CI  to support 
continuous integration in Leo.

- Terry proposes rendering outlines to a canvas 
 and supporting cmap 
.

- Several people, including me, suggest that cross-file searches would work 
around the lack of cross-file clones. This idea has more force now that Leo 
boasts various clone-find command.

- Kent proposes using pyfilesystem 
.

- jasonc proposes various ways to produce more flexible output from Leo.

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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.