Following Up: About org mode.

[john lunzer]

Coming from the recent Org-mode follow up topic I thought would I continue the Org-mode dialogue here after Israel Hands' last post in that thread. This thread is a follow-up to a separate Org-Mode thread that also took place back in Feb. There was a lot of good conversation and a strong call for many Org-mode features. As a disclaimer, it is not my wish/goal for Leo to be emacs. But, emacs is a great piece of software with some great features, and mimicking a few could make day-to-day life within Leo more efficient.

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.

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 might be a good stepping stone).

[Terry Brown]

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

[john lunzer]

On Monday, September 11, 2017 at 11:47:14 AM UTC-4, Terry Brown wrote:

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.

I think this is the feature a lot of people are after (at least what I'm after). It would be wrong to call it simply a "Jupyter notebook view". Depending on how you configure the size of the text-edit area and the visibility of borders this would also be used for Org-mode style viewing. 

In "Continuous view", which would support Org-mode and standard text editing, you could make the text edit areas resize to same number of lines of text that exist in each node and make the borders 1 pix high grey lines that tell you where a nodes starts and stops without adding extra bulk. 

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.

I think if there is any hope of public "beta testing" it has to be in master.

[Edward K. Ream]

On Mon, Sep 11, 2017 at 10:03 AM, john lunzer <lun...@gmail.com> wrote:

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.

​Support for drawers is marked with the "First" label. It will happen as soon as possible, but that is likely to be in November due to an upcoming vacation.

Edward

[Edward K. Ream]

On Mon, Sep 11, 2017 at 11:32 AM, john lunzer <lun...@gmail.com> wrote:

I think if there is any hope of public "beta testing" it has to be in master.

​I agree.  Most of the work should be done in a separate branch and merged into master for better testing.

Edward