I completely agree with Terry. Having integrated view shouldn't be a
sacrifice of outline view and both should be present. LEP prototypes
show they are possible.
Cheers,
Offray
On 22/03/17 10:05, 'Terry Brown' via leo-editor wrote:
On Wed, 22 Mar 2017 06:35:12 -0700 (PDT)
"Edward K. Ream" <[email protected]> wrote:
Up until now, I have never regretted using separate outline and body
panes. For coding especially, there are advantages: all body text is
unindented, regardless of its position in the outline.
However, "embedding" outline text does have advantages, as both the
Quiver overview
<https://github.com/HappenApps/Quiver/wiki/Getting-Started#5---preview-and-presentation>
and the Englebart video <https://vimeo.com/81238285> show. In
particular, outline heads can be "rendered" in place, according to
outline level, context and user preferences.
Unifying the outline and body panes would require changes throughout
Leo. It seems too big a project, but I am playing with the idea. The
Englebart video is tantalizing.
If such a thing were to be done, I think it should be done without
making any changes to Leo ;-)
I think Leo will become much more powerful / flexible when it has
multiple node editor components that are free to act on different parts
of the tree.
In fact I posted a screenshot of a column of Leo Edit Pane (LEP) widgets
which effectively interleave headings and bodies just a couple of weeks
ago.
Of course "no changes to Leo" is disingenuous, Leo will probably
require changes to most efficiently support such components, although
LEP hasn't required any yet.
But if a unified outline editor should arise, I think it should not
replace the exiting tree and body editor, but be an example of one of
these new node editor components that are free to act on different parts
of the tree. The current tree and body panes need not be visible, but
they shouldn't be replaced. It should be possible to have the current
tree and body panes and the new unified editor visible at the same time.
I'm repeating myself but I think it's key that there not be one
component (currently the combination of the tree and body panes) that
can edit a Leo outline, we need more decoupling of editing from the core
Leo outline / data structure.
LEP is an example. I've found it relatively easy to have a QTextEditor
widget editing this node, and a QScintilla widget editing that node,
with the LEP layer handling node selection. Where I've stalled is
getting a LeoQTextEditor widget into the mix.
Perhaps the big shift in thinking is c.p. That would become "the node
selected in the tree". Which it is currently, the difference being for
a given node editor component, that component might not be editing c.p.
So there will be issues to resolve for executing scripts, etc. etc.
Cheers -Terry
Kent has long requested unified *file *views. The VR2 plugin
provides one way to get that for a given tree, but it could be
improved.
Jupyter provides such integrated views without outlines. Links and
TOCs must be entered by hand, but the visual effect is good.
All such options could be called preferences, so it's no good arguing
about them. Leo needs to do better in this regard. #443: Adopt
Quiver Look and Feel
<https://github.com/leo-editor/leo-editor/issues/443> contains links
to many other related issues, so #443 is probably a good enough
placeholder.
Your comments, please.
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.
