On Mon, 23 Jan 2017 13:40:48 -0600
"Edward K. Ream" <[email protected]> wrote:

> On Mon, Jan 23, 2017 at 11:42 AM, john lunzer <[email protected]>
> wrote:
> 
> > Of the code editor's I've used code comparison is encouraged within
> > a single running application, this allows for fancier things like
> > vim's diff mode which looks like github's HTML diffs. If you open
> > up two Leo applications you lose the possibility for this kind of
> > feature. 

Well timed :-)

> ​Interesting.  I wouldn't want to rule that out. Comparisons using two
> different instances of Leo is a workaround...

As I mentioned to Edward in what was probably a GitHub discussion (+1
if you subscribe to all activity on Leo's GitHub it's integrated with
your email and seems seamless, but -1 you lose track of which is GitHub
discussion vs. leo-editor discussion), I've been working on a new node
editing widget for Leo.  It's going well although early days - it's
kind of a container for a non-singleton body text editing widget plus a
rendered view widget.

Attached is a screen shot, which looks odd because the screen shot
software's omitting the window border.

Track - whether or not it follows the node node selection in the tree.

Update - whether or not it updates when the content of its node changes.

Recurse - whether or not the View part is rendered based just on the
current node, or recursively.

Split▾ - a three state button, Edit / Split / View, whether to show
only the Edit or View components, or both.  When showing both... kind
of reminds you of a Jupyter code + output display widget, doesn't it :-)

Render just causes an update of the View component when Update is
disabled

More▾ is where a bunch of other stuff will go, like selecting how to
render (HTML, markdown, execute code and render result as plain text or
some other format), only update once every N seconds for expensive
renders, etc. etc.

In the (very alpha) screen shot, you can see the effect of Recurse
being checked in the View component (lower half), @others is replaced
with descendant nodes.

The point of this widget is to provide a place for paired edit and view
widgets, or just one or the other.  It manages all the tracking / not
tracking, updating stuff etc.

Right now the only view widget is a plain text QTextBrowser with a tan
background :-), and the only edit widget is a plain text QTextEdit.

I think it will be quite easy to add QScintilla as another editor
widget, where supported, and all the expected rendering widgets (HTML,
markdown, rst, etc. etc.).  So in some respects this is
View-Rendered-4, with the advantage of hindsight of all the previous
View-Rendered work.  But also recognizing that the same track / don't
track etc. controls View-Rendered needs also apply to non-singleton body
editors.  As I write I realize I need to add "Follow", like track except
the tree jumps back to the editor's node when the editor's selected.

The goal is to be resolutely non-singleton, and provide a small and simple
API for edit and view widgets.  There will be a lot of view widgets, but I
assume very few edit widgets.  Maybe just QScintilla, Leo's body editor, and
maybe the CKEditor rich text editor.

The challenge, which I'm hoping Edward will help with ;-) will be
getting Leo's body editor to work - particularly the key binding part.  I
realize that supporting Leo's sophisticated key bindings (modes,
abbreviations, control of other parts of Leo, e.g. moving tree selection
while in body editor) add a lot of complexity to implementing Leo's
interface, but are also a major part of Leo's strength.

My plan is to make it work so well with QScintilla and all the
view rendering widgets the need to get the regular Leo body widget in
there will be overwhelming :-)

Cheers -Terry

-- 
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.

Reply via email to