It must be an adage that if you look hard enough you could find anything you need in Emacs. I am happy to report that there appears to be a (near) perfect solution for the question I have raised here regarding using Emacs with Leo.
The answer is to take advantage of the Emacs outline-minor-mode (and supplement it with the outline-cycle of the outline-magic.el). This is a near perfect replacement for editing @auto files in Emacs. Basically it auto detects the code block structure (through regexp defined in your major mode) and it then auto folds the codes if required through selective visibility of texts. So one can load a Python source code file, start the outline minor mode (or have it auto start), cycle through the headline views (top level headlines, all headlines or all texts unfolded). One can also go to any node and do the same there for its subtree. One must use this oneself to see how amazing it is, all achieved with very simple and compact elisp code. Outline nodes can be vertically moved as in Leo, which is great as one can do the same kind of (in-file) code re-org as one would do in Leo. However this is where the near perfection comes in: Outline mode works with regexp to control visibility and movement, but all Emacs text editing are normal text editing without understanding of the outline structure, so one must consider the consequence of one's action w.r.t the outline structure. This should not normally be a problem and the upside is that any newly created node instances are automatically part of the outline structure (if you add a def or a class, e.g.) The downside is that node promotion/demotion won't work for Python, but can be (easily) emulated by simply selecting a node (or multiple nodes) and do block dedent/indent. However one must do so without unexpectedly disturbing the outline: in Leo if you promote a node it is automatically outside of the parent's scope because Leo editor understands the structure; in Emacs with dedent you are only textually promoting the node so you want to be sure that it is moved to the bottom of the siblings first so that no siblings accidentally become its children (and severed from the original parent) after the promotion. If you consider your action textually this is not so hard to understand. So for source code files that work well with @auto, as source code usually provide enough structural hints without manual meta information, this Emacs mode should work great. And it will be seamless with Emacs' major modes and REPL. So my revised approach now is to stay within Emacs for development and debug, but I still prefer Leo's handling of multiple files than Emacs' org-mode approach. So I will continue to use Leo to control a project: reference source files through @auto nodes, additional regular nodes for meta information (reasoning about code, TODOs, issues list, project management scripts etc). It was great to learn about the UNL (Uniform Node Location) from this thread: https://groups.google.com/forum/?fromgroups=#!topic/leo-editor/QNJbxStRT2o It means that I can reference a subnode in an @auto tree through an external @url node. I can then comment so the said node outside of the @auto tree without resorting to cloning (which does not work with @auto subnodes -- it only last through the session and the clonal relationship is forgotten once the Leo file is closed). I am very happy with how the workflow has shaped up. There are still some minor kinks but those should be relatively easy to work out over time. On Thursday, October 18, 2012 1:18:30 PM UTC-7, F.S. wrote: > > > I am thinking a good starting point is to focus on supporting editing of > @auto files in Emacs. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To view this discussion on the web visit https://groups.google.com/d/msg/leo-editor/-/k-y2Hw4cBAcJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
