Really nice work Terry. The most obvious feature that stood out was the "recurse" option. I've long wanted a way to view a node in what I call "edit mode" without creating a separate @edit node and reloading from disk constantly. The downside to an @edit node is that it pollutes the tree and muddies the results of find commands. This new editing node looks like a good solution to that limitation.
On Monday, January 23, 2017 at 8:54:33 PM UTC-5, Terry Brown wrote: > > On Mon, 23 Jan 2017 13:40:48 -0600 > "Edward K. Ream" <[email protected] <javascript:>> wrote: > > > On Mon, Jan 23, 2017 at 11:42 AM, john lunzer <[email protected] > <javascript:>> > > 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.
