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. On Thursday, August 1, 2019 at 7:29:48 AM UTC-4, Edward K. Ream wrote: > > 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 > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/31c42f50-eff7-4761-9c40-337e89b66189%40googlegroups.com.
