Emacs features in Leo: general remarks

[Edward K. Ream]

It will be a lot easier to add emacs features to Leo than add Leonine features to emacs!  I've said this before, but it's worth repeating.

Pyzo already supports features such as dired, integrated outline/body pane and the jupyter console.  Something like magit might exist in the python world.  If not, I'll do it by hand.

Edward

[Chris George]

Why reinvent the wheel? :-)

https://github.com/gitpython-developers/GitPython

Chris

[Edward K. Ream]

On Thu, Aug 1, 2019 at 7:43 AM Chris George <techn...@gmail.com> wrote:

Why reinvent the wheel? :-)

https://github.com/gitpython-developers/GitPython

I have looked at this before.  Iirc, GitPython does surprisingly little. The tree g.Git in leoGlobals.py contains Leo's present git-related infrastructure, and that probably suffices.

Edward

[john lunzer]

The "magic" of emacs is not due to each of these features in isolation (though they are all useful by themselves) but due to their interconnectedness within the context of registers and buffers. Everything in emacs exists within a "buffer" which is really just text windows. As such everything is capable of being copied/moved to another buffer. This is helpful for instance when running a command line utility on a file or group of files within dired using "dired-do-shell-command". It could be something as simple as running md5sum on some files and having instant access to the output in a buffer that can be easily moved to an org file for documentation. This kind of interaction extrapolates out to almost anything you can do in emacs.

I don't want to imply that the "buffer" system is almighty (which it is not) or that Leo should try to emulate it somehow. Buffers are simply the medium through which emacs executes cohesion. Leo's medium are trees and nodes.

While each of the proposed emacs feature is nice, they would become truly powerful if they are well integrated into Leo's tree/node paradigm. I would encourage, as much as is possible integrating these features directly into the dag. I envision a Leo universe where the DAG becomes a lot richer. 

For example I see a reasonable implementation of a Jupyter console as creating a node name "@jupyter my_console" which could then be "activated" or "run", generating a child node named "In [1]:" after the jupyter kernel booted up and was attached. You then type your input into that "In" node and when ready "activate"/"run" the node which would run your command in the jupyter kernel and create a sibling node named "Out [1]" with the output and another sibling named "In [2]" with another input. The idea of a generic "activate"/"run" command command comes from org-mode's "org-ctrl-c-ctrl-c" command. It's a pretty uninspired name but it is a context sensitive command which tries to do what you would expect, so in the case of the "@jupyter my_console" node activating it means starting a kernel. And in the case of "In" nodes activating it means running the code.

With Leo's current body node capabilities the above interaction might be a little cumbersome. However, if Leo had a vertically sequential multi-node body pane (which I mocked up about a month ago) this interaction would be seamless. Being able to save the "@jupyter my_console" sub-tree and move it's children around would have great utility.

The active_path.py plugin already kind of implements dired as a tree, but it's pretty rough around the edges, and would need to be reimagined to provide a true live filesystem view. In the case of integrating dired into the dag you could imagine an "@dired" node with each child representing a file or folder and each body of each child as containing the same information you would see in a "ls -l" listing (or "long listing"), such as file size, owner, modification date, and permissions. 

If different types of "@directive" nodes could dynamically alter the visual style of the child nodes displayed in a multi-node body editor you could for example make the body appear to the left of the headline and remove any upper and lower borders and spacing for children of an "@dired" sub-tree . In this way the sub-tree of "@dired" would look almost exactly like an "ls -l" listing. With the exception that it would still be a dag/tree/nodes all the way down. In the same way you could style the children of an "@jupyter" node to make the visual look and feel of a jupyter notebook.

All of a sudden you have powerful tools that look and behave exactly as people are familiar with but are also true Leo trees. Now try to imagine these features with Vitalije's time machine feature. Leo would undoubtedly be one of the most powerful computing tools in existence, surpassing the might and utility of many other tools/IDEs combined.

Though I haven't suggested anything outside of Leo's existing paradigm there would obviously be an immense amount of work involved in this. I'm not for a second suggesting anybody attempt this. It is merely my vision of what Leo could become.

[Edward K. Ream]

On Thu, Aug 1, 2019 at 12:30 PM john lunzer <lun...@gmail.com> wrote:

Everything in emacs exists within a "buffer" which is really just text windows.

Everything in Leo is an outline, consisting of true Python objects, not just plain text.

While each of the proposed emacs feature is nice, they would become truly powerful if they are well integrated into Leo's tree/node paradigm.

Actually, Leo uses emacs's named commands.  So for instance, implicit in all proposals are the addition of Leo commands.  For instance, pyzo's file browser does what dired does.  But I'll add emacs-like commands (dired-*) so that everything the file browser does can be done a) via a keyboard shortcut or b) via a script.

For example I see a reasonable implementation of a Jupyter console as creating a node name "@jupyter my_console" which could then be "activated" or "run", generating a child node named "In [1]:" after the jupyter kernel booted up and was attached.

We can discuss this later.  For now, I'm happy to use the pyzo code as it is, with the addition of emacs-like commands.

With Leo's current body node capabilities the above interaction might be a little cumbersome. However, if Leo had a vertically sequential multi-node body pane (which I mocked up about a month ago) this interaction would be seamless. Being able to save the "@jupyter my_console" sub-tree and move it's children around would have great utility.

See #1228. It's too early to tell how this will fit into Leo.

The active_path.py plugin already kind of implements dired as a tree, but it's pretty rough around the edges,

Pyzo's file browser is superb.

If different types of "@directive" nodes could dynamically alter the visual style of the child nodes displayed in a multi-node body editor you could for example make the body appear to the left of the headline and remove any upper and lower borders and spacing for children of an "@dired" sub-tree . In this way the sub-tree of "@dired" would look almost exactly like an "ls -l" listing. With the exception that it would still be a dag/tree/nodes all the way down. In the same way you could style the children of an "@jupyter" node to make the visual look and feel of a jupyter notebook.

Pyzo's file browser could display ls-style listing in an optional "nerd mode" ;-)

All of a sudden you have powerful tools that look and behave exactly as people are familiar with but are also true Leo trees.

That's not my goal.  If people want emacs, they know where to find it.

Now try to imagine these features with Vitalije's time machine feature. Leo would undoubtedly be one of the most powerful computing tools in existence, surpassing the might and utility of many other tools/IDEs combined.

Leo already is that ;-)

Edward

[Edward K. Ream]

On Thursday, August 1, 2019 at 12:30:32 PM UTC-5, john lunzer wrote:

The "magic" of emacs is not due to each of these features in isolation (though they are all useful by themselves) but due to their interconnectedness within the context of registers and buffers.

Yes, I think I understand that.

Rereading my reply to your comments, you might think I was blowing you off.  Instead, I was attempting to say that each new emacs-like feature must be integrated with Leo as it is.  Yes, big visions are important, but the overall vision is Leo as it is, not emacs as it is.

As we go forward, I will welcome specific suggestions to emacs-like features.  But let's get each feature working first.

Edward

[john lunzer]

Thank you for circling back around, it's absolutely appreciated. I agree with you fully; I just sometimes have these grand visions of Leo and want to share them. The dynamic node styling seemed like a potentially simple solution to shoehorning various features into the DAG. I'm such a huge fan of Leo's DAG (I miss it every day when using other tools) and generally feel that is where the investment should be because it feels more "true" to Leo's essence. 

[Offray Vladimir Luna Cárdenas]

Hi,

On 1/08/19 12:30 p. m., john lunzer wrote:
> I don't want to imply that the "buffer" system is almighty (which it
> is not) or that Leo should try to emulate it somehow. Buffers are
> simply the medium through which emacs executes cohesion. Leo's medium
> are trees and nodes.
>
> While each of the proposed emacs feature is nice, they would become
> truly powerful if they are well integrated into Leo's tree/node
> paradigm. I would encourage, as much as is possible integrating these
> features directly into the dag. I envision a Leo universe where the
> DAG becomes a lot richer. 
>
> For example I see a reasonable implementation of a Jupyter console as
> creating a node name "@jupyter my_console" which could then be
> "activated" or "run", generating a child node named "In [1]:" after
> the jupyter kernel booted up and was attached. You then type your
> input into that "In" node and when ready "activate"/"run" the node
> which would run your command in the jupyter kernel and create a
> sibling node named "Out [1]" with the output and another sibling named
> "In [2]" with another input. The idea of a generic "activate"/"run"
> command command comes from org-mode's "org-ctrl-c-ctrl-c" command.
> It's a pretty uninspired name but it is a context sensitive command
> which tries to do what you would expect, so in the case of the
> "@jupyter my_console" node activating it means starting a kernel. And
> in the case of "In" nodes activating it means running the code.

I have advocated for something similar. I don't know what can be
borrowed from Pyzo (and if this is necessary). But I would like to see
something like an IPython kernel that computes Leo In nodes and produces
Leo Out Nodes. Leo directives can be used to traverse such tree,
updating computations, using outputs to create reports and so on.

Cheers,

Offray