On Mon, 11 Sep 2017 08:03:47 -0700 (PDT) john lunzer <lun...@gmail.com> wrote:
[snip] > There is a continued desire for displaying multiple nodes at once, to > get a better feel for the overall content of a tree. I believe that > Terry's work will address this and that once he releases what he has > been working on that others will be able to contribute and help > refine the vision for what a multi-node edit pane should be. Just want to clarify what the leo_edit_pane branch aims to do. Basically provide a body editing and or viewing element that is designed to be non-singleton and not necessarily editing / viewing the node selected in the tree. More specifically it's a compound widget with some controls for managing (de)synchronization with the node selected in the tree and an editing and a viewing area. The edit a view elements can be displayed both at once or one or the other. It supports multiple actual edit and view widgets, e.g. for edit QTextEdit, QScintilla, and hopefully soon the Leo text editing widget with its syntax coloring and key-strokes, although not yet. For view, all sorts of possibilities, but Qt web viewer based widgets that show rendered markdown, rst, etc. are the low hanging fruit. Also one that shows the output of executing the node's code would be an obvious one. For multi-node editing, another layer not yet started but perhaps a good next step, would be a separate widget that manages a vertical stack (scrolling area) of these edit/view widgets. In the case where the view half was visible and showing the results of code execution, this would basically be a Jupyter notebook view. Separately, there's the issue of how Leo handles widgets / panes and their arrangement (and persistence). Currently we have the "easter egg" free layout system hidden on the context menu of the pane dividers. It works, but is too unintuitive to be ideal, I've started work to replace it with a QDock approach. So like all widgets/panes, the new edit/view widget will be easier to manage with the QDock interface, but that can wait. Currently there's a couple of small snippets of code needed to open the edit_pane widget - probably the best next step is to make those into g.commands to it's easier for people to see / test the new code. Question: who many people will look at / test it if it stays in a separate branch? Alternative is to merge it into master, which would require this change in core: https://github.com/leo-editor/leo-editor/commit/d9dcffea2655c12c53762053e9ba2a6564266b1f#diff-ed64e2876398e232da95328f1bf78e65 That has a detectable but I think ignorable performance hit, but we should discuss. Cheers -Terry > Another strong call was for better within-pane rendering > (specifically Latex, but I think this would extend to other rendering > as well). > > In addition Edward listed: > > - An agenda plugin (possibly built on the To Do plugin) > - Node drawers for "hidden" information (basically an easy way to > edit node uA ) > - Better shell support > - Better language support (make, C, C++, Java)? > > Of these it seems like Agenda has public interest. > > It seems either people don't understand the need for drawers or > simply don't see them as I high priority item over many of the other > org-mode features. > > Once there is a multi-node editor in place I plan on giving serious > thought to better shell support (the sh library > <https://amoffat.github.io/sh/> might be a good stepping stone). > > -- 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.
