work flow questions

[F.S.]

I have used Leo for a long time but I probably only use 1% of Leo features :-) I have been using it to do book keeping in Python. I created some simple classes and as things happen I add instances to record the new events. I use the outline to organize these by time periods. I write Python functions as needed to query the database (of Python instances). I use Leo's scripting capability and the handy script-button to run queries and send the query results directly into the log pane. I could do all this within Leo. It is simple and it just works and I am very happy with it.

While I was helping with the scroll bug I poked around Leo code base a bit and I am impressed by how the source files can be referenced from a few Leo files. The files loaded quite fast. When I do find in an outline I am essentially grepping all the files. Navigating through the nodes take a bit getting used to as with cloning node/file correspondence isn't assured, but I can see that it is a powerful way to organize for the creator who is intimately familiar with the structure of things. Also it is impressive how source code can be re-orged on a large scale fairly easily so logistics does not stand in the way of pursuing clarity through the best organization possible. I also like the cweb idea in general so I am definitely interested in using Leo more as a development tool and write my own code in outline/cweb style.

Currently I use Emacs. I can use it as a complete IDE since I can run inferior processes. I can do REPL style code development and debug. I also use it as my gui to visualize and navigate through large data structures. I use tree-buffer to visualize tree type structures and associate actions with tree nodes that allow me further explore the underlying data. If I need to look at a data table I just dump the output into an org-mode buffer and run org-table on the output. I use w3m to render html text in any buffer. I can create buttons to help me remember complex actions. I have not used the org mode's outlining capability, since I know Leo is an excellent outliner. I am wondering what kind of work flow I can use if I want to start using Leo as the source code editor? The simplest thing to do is to probably use @file trees. But if I then do REPL in Emacs, I will be looking at a lot of sentinels. I assume that I can edit the code in Emacs without ruining the outlining as long as I don't touch the sentinels. Now if I use @asis trees instead so I don't see sentinels -- does that mean that I won't be able to edit the code in an external program and have the changes reflected back in Leo?

I also use Vim because of its lightweight. It starts up quickly and uses very little resource so I can run as many copies of it as I want without thinking. I use it to look at large code bases in conjunction with cscope and it works very efficiently.

Because of the scroll bug I have also been keeping notes in Vim instead of Leo, using VIm's fold capability. I am thinking of moving these notes back to Leo. Is there a way to automate the conversion of Vim folds into outline nodes?

[Terry Brown]

> Now
> if I use @asis trees instead so I don't see sentinels -- does that mean
> that I won't be able to edit the code in an external program and have the
> changes reflected back in Leo?

Yes, but there's also the @shadow and @auto nodes. @auto reads plain
source code so mixing editors is straight forward (given the usual
potential for overwriting changes with multiple simultaneous edits of
the same file). But @auto doesn't allow you to use Leo's code outline
organization features to the same degree. @shadow does, it keeps the
Leo info. in a separate shadow file, so the source is still plain. But
it's probably not that heavily used.

I use @auto and if needed the features of the bookmarks.py plugin.

Cheers -Terry

[F.S.]

Here are my current thoughts w.r.t. work flow using Leo:

1) I will most definitely continue using Leo for the things I already use it for, where it is natural fit.

2) Now that Edward is getting a handle on the scroll issue, I have a better understanding of the performance issue related to syntax color and how the vr mode works, I am really looking forward to moving my documentation work into Leo to better take advantage of outlining and reST markup.

3) I will for now continue to use Emacs as my primary IDE. There are a couple of things that are lacking with Leo here: 

a) is the strength of Leo is also a weakness. In Emacs since the text is not structured every buffer is also an editor. I can easily dump program output into a buffer and do post processing or impromptu search. In Leo the outline is the central focus. For example I don't know how to search for things in the log pane if that capability does exist.

b) is the lack of an inferior python (or other language) processes to enable REPL development. Scripting is nice but I don't really want to run real code in my editor python, with name pollution and real possibilities of occasional crashes.

c) is the lack of dabbrev support for now. codewise is impressive but when I am writing new code dabbrev really makes it easier to use meaningful names.

4) Leo is a great tool for refactoring and I plan to take advantage of that. I also plan to keep much larger source files instead of arbitrarily splitting source codes into many files. Leo will make navigation easy. I will most likely use the @auto mode instead of @shadow (thanks Terry for the suggestions!) and frequently move between Emacs and Leo (with some vim sessions sprinkled in as appropriate).

As I learn more about Leo my approach will surely evolve along with Leo.

[Edward K. Ream]

On Mon, Oct 1, 2012 at 5:50 PM, F.S. <speec...@gmail.com> wrote:

> 3) I will for now continue to use Emacs as my primary IDE. There are a
> couple of things that are lacking with Leo here:
> a) is the strength of Leo is also a weakness. In Emacs since the text is not
> structured every buffer is also an editor. I can easily dump program output
> into a buffer and do post processing or impromptu search. In Leo the outline
> is the central focus. For example I don't know how to search for things in
> the log pane if that capability does exist.

In Leo, every *node* is equivalent to an Emacs buffer. Just dump
something into a new node, and search that node. You can copy text
from the log pane using Ctrl-V.

> b) is the lack of an inferior python (or other language) processes to enable
> REPL development. Scripting is nice but I don't really want to run real code
> in my editor python, with name pollution and real possibilities of
> occasional crashes.

There is no name pollution in a Leo script, unless you go out of your
way to pollute Leo, by assigning to an attribute of c, g or p.

Python crashes in Leo scripts have absolutely no effect on Leo itself.
The only way to take a hard Python crash in a Leo script is if the
script messes with Leo's gui widgets, but that is impossible to do by
mistake. I took a hard crash yesterday while messing with the
internals of syntax coloring, but I was running in test.leo, so I just
restarted it. I didn't lose anything because I saved test.leo first,
as I usually do before running a script ;-)

Leo could use better support for running scripts in a separate
process. This would eliminate the need to use Python's subprocess
module in the Leo script. Usually, this is *not* what you want, but
it is sometimes useful.

> c) is the lack of dabbrev support for now. codewise is impressive but when I
> am writing new code dabbrev really makes it easier to use meaningful names.

We'll fix this today, you and I.

> As I learn more about Leo my approach will surely evolve along with Leo.

Yes it will. For instance, you'll fall in love with Leo scripting :-)

Edward

[F.S.]

Wow that was fast! That will make it much easier for me to use Leo as THE source code editor.

 

> a) is the strength of Leo is also a weakness. In Emacs since the text is not
> structured every buffer is also an editor. I can easily dump program output
> into a buffer and do post processing or impromptu search. In Leo the outline
> is the central focus. For example I don't know how to search for things in
> the log pane if that capability does exist.

In Leo, every *node* is equivalent to an Emacs buffer.  Just dump
something into a new node, and search that node.  You can copy text
from the log pane using Ctrl-V.

Good point. In Emacs I can dump comma (or some other delimiter) separated data into a buffer and run org-table on it and viola I get the data all nicely tabulated. With Leo scripting this should be doable too. However in Emacs it is easy to attach arbitrary action to any text through buttons that can be placed anywhere in any buffer. So for example if one of my table entry is a large block of html text I can place a button in its place and only render the text somewhere if I click on the button. I can use this to interact with large tree like data structures as well so I can easily expand or contract nodes and take actions associated with the nodes. In Leo I could map the same structure to outline nodes? But that seems a bit heavy handed as these are for transient data exploration.

> b) is the lack of an inferior python (or other language) processes to enable
> REPL development. Scripting is nice but I don't really want to run real code
> in my editor python, with name pollution and real possibilities of
> occasional crashes.

There is no name pollution in a Leo script, unless you go out of your
way to pollute Leo, by assigning to an attribute of c, g or p.

Python crashes in Leo scripts have absolutely no effect on Leo itself.

I have large data sets that take time to load and process into Python memory. Somehow it feels hazardous to load them into the same process as my editor :-) But it is also more than just running user code in a separate process: 

With Emacs, I can easily run the inferior Python interactively through the comint where I get the Python prompt. With Leo I can simulate this by writing code in a script node and redirect the output to the log pane.

With Emacs I can also write/modify code in any source buffer and test the code out immediately by incrementally sending them to the interpreter (through eval string, eval region or eval function/class def). This is tremendously effective for exploratory coding.* Can I do something along the same line in Leo?

* Yes that does mess up the namespace that may have to be taken care of later but it is well worth the effort. I also plan to, with Leo's help, keep source codes in as few files as possible. I prefer Lisp style large top level symbol table over arbitrary modules esp as one can already wrap things in a class if necessary.

Leo could use better support for running scripts in a separate
process.  This would eliminate the need to use Python's subprocess
module in the Leo script.  Usually, this is *not* what you want, but
it is sometimes useful.

> As I learn more about Leo my approach will surely evolve along with Leo.

Yes it will.  For instance, you'll fall in love with Leo scripting :-)

That is the plan! :-)

 

Edward

[Edward K. Ream]

On Tue, Oct 2, 2012 at 12:44 PM, F.S. <speec...@gmail.com> wrote:

> Good point. In Emacs I can dump comma (or some other delimiter) separated
> data into a buffer and run org-table on it and viola I get the data all
> nicely tabulated. With Leo scripting this should be doable too.

Yes.

> However in
> Emacs it is easy to attach arbitrary action to any text through buttons that
> can be placed anywhere in any buffer.

That's what Leo's script buttons do. A script button script could act
on the entire file (as in Emacs) or on the presently selected node
(typical) or on a found set of nodes, say all the nodes with
@something in the headline.

So if you *only* consider nodes to be equivalent to emacs buffers,
@button scripts are just as powerful as emacs buttons. But in
addition, @button scripts have full, easy access to all aspects of
Leo's outline structure. Thus, Leo scripts can easily do things that
would be extremely laborious in emacs.

> I have large data sets that take time to load and process into Python memory. Somehow it feels hazardous to load them into the same process as my editor :-)

Your intuition is probably faulty. Loading large data into Leo should be safe.

> With Emacs, I can easily run the inferior Python interactively through the
> comint where I get the Python prompt. With Leo I can simulate this by
> writing code in a script node and redirect the output to the log pane.

Yes, you could do that. Or you redirect output to any node.

> With Emacs I can also write/modify code in any source buffer and test the

> code out immediately by incrementally sending them to the interpreter.

> (through eval string, eval region or eval function/class def). This is
> tremendously effective for exploratory coding.* Can I do something along the
> same line in Leo?

Of course you can! That's what Leo's Ctrl-B (execute-script) does.
But unlike flat editors, Ctrl-B composes the script from the node and
all it's descendants if you use @others or section references. For
example:

<< imports >>
@others
sc = ScriptController(c)
sc.run()

The ScriptController class will be defined in child node of this node.
This class could be complex, defined in many different nodes.

And to repeat, all Leo scripts have full access to all data in all Leo nodes.

> * Yes that does mess up the namespace that may have to be taken care of
> later but it is well worth the effort.

Executing scripts is safe. For details, look at the code in c.executeScript.

> I also plan to, with Leo's help, keep
> source codes in as few files as possible. I prefer Lisp style large top
> level symbol table over arbitrary modules esp as one can already wrap things
> in a class if necessary.

No problem. Leo's source files are very large compared to typical
practice for much the same reason.

Edward

[F.S.]

On Tuesday, October 2, 2012 11:18:10 AM UTC-7, Edward K. Ream wrote:

Of course you can! That's what Leo's Ctrl-B (execute-script) does. 

Doc string says "We execute the selected text, or the entire body text if no text is selected." Yes that is exactly what I was looking for, 

On Tue, Oct 2, 2012 at 12:44 PM, F.S. <speec...@gmail.com> wrote:

> However in
> Emacs it is easy to attach arbitrary action to any text through buttons that
> can be placed anywhere in any buffer.

That's what Leo's script buttons do.  A script button script could act
on the entire file (as in Emacs) or on the presently selected node
(typical) or on a found set of nodes, say all the nodes with
@something in the headline.

So if you *only* consider nodes to be equivalent to emacs buffers,
@button scripts are just as powerful as emacs buttons.  But in
addition, @button scripts have full, easy access to all aspects of
Leo's outline structure.  Thus, Leo scripts can easily do things that
would be extremely laborious in emacs.

I think we have a little misunderstanding of what emacs buttons are. They are close cousins of text-properties. They make any text (a word, a character or a region) clickable by associating function hooks to the text, akin to hyperlinks.  This is very useful for exploring data by making the data active. The context of the action is already provided by the text you click on. For example if I were to generate a tree I could embed different actions at different nodes based on the knowledge I have about the data structure. @buttons are powerful but they perform a different function.

 

> * Yes that does mess up the namespace that may have to be taken care of 

> later but it is well worth the effort.

Executing scripts is safe.  For details, look at the code in c.executeScript.

What I was referring to was that when we eval everything at the top level of course we break all the module restrictions. And intermingled with interactive sessions, it is easy to interactively set something but then to forget to have it in the actual code. This is part and parcel of the methodology, not something peculiar about Leo or Emacs. But it is a small price to pay for the benefits of REPL and the pitfalls can be mitigated through care. 

Thanks for the education. I am learning more of Leo's power as the hours go by, literally.

[Free Speech]

Oh, I forgot to mention that there is a big plus for running in the
same process as the editor. In Emacs the communication with the
inferior process comes at a price. I had to serialize the data
(through json and through a file) that I pass between elisp and
python. Running in the same process as the editor means the Leo script
has direct access to my data, which makes exploring data even more
natural.

[Edward K. Ream]

On Tue, Oct 2, 2012 at 5:06 PM, F.S. <speec...@gmail.com> wrote:

> I think we have a little misunderstanding of what emacs buttons are. They are close cousins of text-properties. They make any text (a word, a character or a region) clickable by associating function hooks to the text, akin to hyperlinks. This is very useful for exploring data by making the data active.

This would make a good plugin, imo. Qt supports hyperlinking, and the
plugin could associate hyperlinks with nodes using the so-called user
data in p.v.u.

> What I was referring to was that when we eval everything at the top level of course we break all the module restrictions.

I have no idea what you are worried about. Yes, using g, c and p
scripts can access all data and all of Leo's source code, but the
access is perfectly controlled and has never, to my knowledge, caused
any problems whatever.

> And intermingled with interactive sessions, it is easy to interactively set something but then to forget to have it in the actual code.

Yes, you could set ivars or redefine methods or functions from, say,
pdb, but I've never been tempted to do that, nor do I see that it
would be that useful to do that.

This FAQ entry describes how I safely use Leo to develop itself:
http://webpages.charter.net/edreamleo/FAQ.html#how-can-i-use-leo-to-develop-leo-itself

The trick is that you test Leo (or any "unsafe" script) in a separate
copy of Leo, which should load very quickly, and which you can invoke
using only one or two keystrokes.

HTH.

Edward

[F.S.]

I agree with you. I love REPL. That is how a dynamic language should be used. Otherwise I might as well use a compiled one and get the benefits of static analysis.

I don't have the luxury of quick restart as preprocessing data takes too much time for me, so I redefine classes and functions all the time in the same session. I run top level interactively to explore (post process) data.

I was arguing against myself to point out some potential pitfalls. I don't claim they are a big problem, just something to be aware of.

On Friday, October 5, 2012 5:35:47 AM UTC-7, Edward K. Ream wrote:

On Tue, Oct 2, 2012 at 5:06 PM, F.S. <speec...@gmail.com> wrote:

> What I was referring to was that when we eval everything at the top level of course we break all the module restrictions.

I have no idea what you are worried about.  

Let's say we are working on a class/function that we are changing frequently and we don't want to restart every time. If we put our function in a module, in order to redefine it we can reload the whole module. But we want to be careful so that reloading the module doesn't create unwanted side effect. If that is impossible we need to just redefine the function without reloading the whole module. We probably need to do something like this: first define the function in top level, then rebind the module.function_name to the new definition at the top level. This is only possible if we have been very careful about scoping rules so that non-local symbols (global vars, imported names) referred to in the function body are always resolved consistently. The module system could interfere with REPL flow. I prefer the Lisp way of long meaningful symbol names instead of relying on the module system to keep namespaces separate.

[F.S.]

The more REPL friendly languages (Common Lisp e.g.) provide a way to switch the namespace that the interpreter is in at any time. That way the package/module system no longer hinders REPL.

[F.S.]

Some updates on the work flow. I have been moving between Leo and Emacs and I am quite happy with the results, although there are some glitches too.

I am now using Leo as the project manager and the primary source code editor to write new code and/or refactor existing code. I had some third party software that I wanted to prune down the features and use on a server.  Some files should be copied from the original, some files are majorly pruned to cut down references to unused features and remain as skeletons just to keep things happy and a few needed to be rewritten to fit the server side. It is pretty simple to keep a separate list of each and manage copying, updating etc all from within Leo. I can probably do the same if I had enough sophistication with version control software, but I suspect that I suffered much less frustration by using Leo (and shutil.copy2) to manage the flow. It is a powerful combo to document meta information: source code management info and script, reasons for doing things, alternatives that failed or should be tried etc, all in the same outline with the code base, knowing that I will have a much easier time if in the future I need to revisit the code and choices made.

For code completion Codewise was kind of disappointing. Maybe it is something about how my tags are set up. I can see why it is not turned on as default. I am sure it is great (indispensable) if I want to hack Leo. For now I am just surviving on dabbrev, which thankfully fits the need well enough.

I also recently learned about the Emacs Occur mode. If any Emacs user here hasn't tried it you've got to give it a try. Do M-X occur, for Python code then give it the pattern "def \|class " (note the space after def and class keywords) and you get an Occur mode window that is eerily similar to Leo! You can navigate around your source code window by clicking on the highlighted links in the Occur mode window. This definitely fits well with one's use pattern of Leo.

Switching between two editors definitely has its own risks. I thought I was careful but still there were one or two things that slipped through. Bugs I must have fixed -- since my REPL session was happy -- but only in my Emacs, were then stomped by my Leo editing session. I was probably keeping the same REPL session for too long, only incrementally evaling new codes as they were created or fixed. A restart quickly showed that mistakes were made, thankfully all easy to fix. I should probably also give (global-auto-revert-mode t) a try.

It is probably not too hard to create an Emacs mode for Leo? With Leo's core outlining and Python scripting capability integrated with Emacs power in basic editing and countless modes. One can always dream, right?

[HaveF]

On Wed, Oct 10, 2012 at 8:50 AM, F.S. <speec...@gmail.com> wrote:

Some updates on the work flow. I have been moving between Leo and Emacs and I am quite happy with the results, although there are some glitches too.

I am now using Leo as the project manager and the primary source code editor to write new code and/or refactor existing code. I had some third party software that I wanted to prune down the features and use on a server.  Some files should be copied from the original, some files are majorly pruned to cut down references to unused features and remain as skeletons just to keep things happy and a few needed to be rewritten to fit the server side. It is pretty simple to keep a separate list of each and manage copying, updating etc all from within Leo. I can probably do the same if I had enough sophistication with version control software, but I suspect that I suffered much less frustration by using Leo (and shutil.copy2) to manage the flow.

I agree. If use VCS to do this, one must manage code line by line, but with leo, we can manipulate section by section.
 

It is a powerful combo to document meta information: source code management info and script, reasons for doing things, alternatives that failed or should be tried etc, all in the same outline with the code base, knowing that I will have a much easier time if in the future I need to revisit the code and choices made.

For code completion Codewise was kind of disappointing. Maybe it is something about how my tags are set up. I can see why it is not turned on as default. I am sure it is great (indispensable) if I want to hack Leo. For now I am just surviving on dabbrev, which thankfully fits the need well enough.

I also recently learned about the Emacs Occur mode. If any Emacs user here hasn't tried it you've got to give it a try. Do M-X occur, for Python code then give it the pattern "def \|class " (note the space after def and class keywords) and you get an Occur mode window that is eerily similar to Leo! You can navigate around your source code window by clicking on the highlighted links in the Occur mode window. This definitely fits well with one's use pattern of Leo.

Switching between two editors definitely has its own risks. I thought I was careful but still there were one or two things that slipped through.

My workflow is similar. Use leo as project manager, use other editor as the primary source code editor. Yes, switching them definitely has risks, sometimes I changed the code in my editor, save..., I HAVE TO refresh that file in leo, and do some manipulations in leo, save...,and return to my editor. Most editor can autoreload the changes made by leo, but leo seems don't have such function(autoreload or autorefresh?), so I have to use them carefully.
 

Bugs I must have fixed -- since my REPL session was happy -- but only in my Emacs, were then stomped by my Leo editing session. I was probably keeping the same REPL session for too long, only incrementally evaling new codes as they were created or fixed. A restart quickly showed that mistakes were made, thankfully all easy to fix. I should probably also give (global-auto-revert-mode t) a try.

It is probably not too hard to create an Emacs mode for Leo? With Leo's core outlining and Python scripting capability integrated with Emacs power in basic editing and countless modes. One can always dream, right?

On Monday, October 1, 2012 3:50:05 PM UTC-7, F.S. wrote:

As I learn more about Leo my approach will surely evolve along with Leo.

--

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/-/awl88Bnn8IUJ.

To post to this group, send email to leo-e...@googlegroups.com.
To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.

--
--
Sincerely,

HaveF

[Edward K. Ream]

On Tue, Oct 9, 2012 at 7:50 PM, F.S. <speec...@gmail.com> wrote:

> I also recently learned about the Emacs Occur mode.

Thanks for mentioning this.

> It is probably not too hard to create an Emacs mode for Leo? With Leo's core outlining and Python scripting capability integrated with Emacs power in basic editing and countless modes.

Are you familiar with the "Leo and Emacs" chapter?
http://webpages.charter.net/edreamleo/emacs.html
This makes Leo outlines accessible from emacs.

Furthermore, much of Leo could be considered an emacs mode: I (or
others) have moved ideas from Emacs to Leo. Dynamic abbreviations are
only the latest in a long line of improvements inspired by emacs.

But you might have been asking whether it would be possible to do a
"Leo" mode in elisp within emacs itself. That would be a *big*
project. The major tasks:

- Rewrite all the code in leoNodes.py. To simulate Leo's DOM.

- Provide wrappers for the many frequently-used methods in
leoCommands.py and leoGlobals.py. For compatibility with existing
scripts.

- Rewrite all the code in leoAtFile.py and leoShadow.py. To simulate
Leo's @file capabilities.

- Provide some way to support plugins written in *Python*.

etc.

I'm not going to do this. Not because it's technically infeasible,
and not because it's a bad idea, but because I wouldn't use the
result. I love Leo, and have no real desire to use emacs.

If this project ever happens it will happen because the lead developer
(not me) will:

a) actually write and thoroughly test the elisp code and
b) actually support the code.

Imo, the only way to support a significant code base is to care enough
about it to use it every day.

**Important**: I would be happy if some power emacs and Leo user
actually did all this. It would ensure that Leo would achieve some
kind of immortality :-) But I am not the one to do this. I can't
bear to look at elisp code, much less write and debug it.

Edward

[F.S.]

On Wednesday, October 17, 2012 5:18:57 AM UTC-7, Edward K. Ream wrote:

On Tue, Oct 9, 2012 at 7:50 PM, F.S. <speec...@gmail.com> wrote:  

> It is probably not too hard to create an Emacs mode for Leo? With Leo's core outlining and Python scripting capability integrated with Emacs power in basic editing and countless modes.

Are you familiar with the "Leo and Emacs" chapter?
http://webpages.charter.net/edreamleo/emacs.html
This makes Leo outlines accessible from emacs.

Yes I have read through that and the Leo Pymacs interface code. I understand the scripting interface is there. But one still needs to bridge the gap between basic text editing and outline editing inside Emacs. 

Furthermore, much of Leo could be considered an emacs mode: I (or
others) have moved ideas from Emacs to Leo.  Dynamic abbreviations are
only the latest in a long line of improvements inspired by emacs.

Yes that was great but do you plan to fix the inconsistencies with Emacs? I understand Leo's strength in outlining and scripting. Fixing all the basic editing/gui problems may seem trivial or burdensome. If you plan to perfect Leo editing as well the desire for an Emacs interface could be less urgent. Here are a few I have encountered and believe should be fixed for better keyboard editing experience:

Kill-line:  in Leo kills the whole line, not just from point to line end. Consecutive kills should be put together so that they can all be yanked at once.

Yank: only yank the most recent out of the kill-line. Should be able to yank consecutive kill lines. Also yanked texts are currently highlighted which means one has to get rid of the selection first before continuing typing. Is there a M-Y as well so that we can reach deeper into the kill-ring?

Mark: I couldn't get mark to work so I have no way to select text from  keyboard instead of using a mouse.

Also for dabbrev, Emacs uses some kind of proximity measure so that if you use M-/ you get the best completion choice right away, and you can cycle through other choices by pressing M-/ again. C-M-/ gets you the longest common prefix and a choice menu if you press the keys again.

Scroll: outline pane still rescrolls when I save.

But you might have been asking whether it would be possible to do a
"Leo" mode in elisp within emacs itself.  That would be a *big*
project.  The major tasks:

No I was thinking of the Leo "server" mode approach. But thanks for sketching out the porting approach as that illuminates where the important pieces/interfaces are at. And I am glad that you do have an interest in getting Leo to Emacs users. I started a wiki page on github:

https://github.com/fspeech/mcleo/wiki/Planning

Unfortunately I am not a power user of Emacs or Leo. I am just very interested in getting the best IDE experience out of the two, which I believe is powerful and unique among all the IDEs out there. Anyone who is interested in getting Emacs and Leo to work together are welcome to edit the page and contribute ideas. And of course your help/advice will be critical if this is going to get anywhere.

Right now I am still trying to get the big picture right: how do we interface with the outline structure in Emacs? Suppose we have one buffer corresponding to the body pane in Leo, this buffer will be constantly refreshed as we switch the current node in focus. Different node may work in different Emacs mode. Hopefully constantly switching editing mode is well tolerated by Emacs. 

Pymacs also seems dated. Emacs now has built-in support for transaction queues for communicating with async subprocesses.

 

-**Important**:  I would be happy if some power emacs and Leo user

[F.S.]

That is very good advice. I am thinking a good starting point is to focus on supporting editing of @auto files in Emacs. Is it possible to have Leo expose an interface for parsing and editing @auto nodes? Here is the usage pattern:

In Emacs open a file as usual. A command will then starts Leo in a Python sub process and send the buffer to Leo to compute the node structure. Take the node structure returned from Leo and display it in a Emacs tree buffer. Tree buffer can then be used for navigation. Use Emacs visibility control to display nodes in the edit buffer as desired -- we could hide all nodes not in focus or optionally show more context nodes (this could potentially be richer than the current Leo Qt GUI). 

Text editing is done as normal in Emacs. Outline editing will be done through Leo. To edit the outline, Leo node will have to be mapped to Emacs buffer line numbers and node operations into Emacs line/region edits. So moving a node, e.g., can be translated into appropriate kill and insert of the corresponding text in the Emacs buffer.

Indentation level in Emacs shouldn't be changed based on node visibility so as not to mess with the undo tree. This could require extra translation when updating Leo with text changes.

Keeping Emacs and Leo in sync can be tricky: as we edit text in Emacs do we figure out which node we are editing and update Leo just on that node? This would require more intelligence on the Emacs side if we make more than one nodes visible at a time -- or we have to limit visibility to one node only so we always know which node is being edited and update Leo with changes whenever nodes are switched. Or alternatively we can ask Leo to recompute the whole outline structure again whenever line numbers are changed, potentially a performance hit. The best way to start is probably to imitate Leo body pane and show one node a time in the Emacs buffer.

Scripting can be done in a separate buffer. Since we do text editing in Emacs scripts should not touch body text and should only work on the outline structure. Basically Leo is used to compute and maintain the outline structure for a single file and run scripts if necessary.

As a starting point I think this is fairly clean but it does require Leo to support the concept of working with just an @auto sub outline instead of with a whole outline.

On Wednesday, October 17, 2012 5:18:57 AM UTC-7, Edward K. Ream wrote:

Imo, the only way to support a significant code base is to care enough
about it to use it every day.

Edward

[Edward K. Ream]

On Thu, Oct 18, 2012 at 12:57 PM, F.S. <speec...@gmail.com> wrote:

>>> It is probably not too hard to create an Emacs mode for Leo?

> Do you plan to fix the inconsistencies with Emacs?

Whenever possible and whenever it makes sense.

> Here are a few [inconsistencies between Leo and emacs] I have encountered:

> Kill-line: in Leo kills the whole line, not just from point to line end. Consecutive kills should be put together so that they can all be yanked at once.

> Yank: only yank the most recent out of the kill-line. Should be able to yank consecutive kill lines. Also yanked texts are currently highlighted which means one has to get rid of the selection first before continuing typing.

Please post wish-list bugs for these yank/kill features.

> Is there a M-Y as well so that we can reach deeper into the kill-ring?

No, iirc.

> Mark: I couldn't get mark to work so I have no way to select text from keyboard instead of using a mouse.

Mark/unmark definitely works. The default setting is Ctrl-M. This
will toggle the mark on the selected node.

> Also for dabbrev, Emacs uses some kind of proximity measure so that if you use M-/ you get the best completion choice right away, and you can cycle through other choices by pressing M-/ again. C-M-/ gets you the longest common prefix and a choice menu if you press the keys again.

I am aware of this difference. Imo, the present operation (with tab
completion) is good enough--possibly better than the emacs way.

> Scroll: outline pane still rescrolls when I save.

Save no longer scrolls. Please update to the latest bzr version.

>> But you might have been asking whether it would be possible to do a "Leo" mode in elisp within emacs itself. That would be a *big*
project.

Maybe not. It might be possible to use all the code in the leoBridge
module. That way all you need are elisp wrappers for the Python
methods you need to use. This is not only much easier to do, it is
safer and better: your code will automatically track changes to Leo:
all you have to do is update the bridge code.

> Pymacs also seems dated. Emacs now has built-in support for transaction queues for communicating with async subprocesses.

Interesting.

Edward

[Edward K. Ream]

On Thu, Oct 18, 2012 at 3:18 PM, F.S. <speec...@gmail.com> wrote:

> Is it possible to have Leo expose an interface for parsing and editing @auto nodes?

Great question. The simple answer is yes: *all* of Leo's source code
is available to any python program. For example::

at = c.atFileCommands

binds at to the atFileCommands "subcommander" for c. This
subcommander is the way to get access to *all* of the code in
leoAtFile.py (!!)

Aha! The leoBridge gives you complete access all of Leo's source
code. This means that you should be able to create elisp wrappers for
*any* of Leo's python code. For example, try this in a Python interp
(**not** Leo)::

import leo.core.leoBridge as b
b = b.controller()
c = b.openLeoFile('') # Open an empty file just to get c.
print(c.atFileCommands)

You can do much the same using pymacs. As a result::

**There is no need to rewrite Leo's code in elisp.**

Edward

[F.S.]

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.

[Edward K. Ream]

On Wed, Oct 24, 2012 at 1:26 AM, F.S. <speec...@gmail.com> wrote:

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

Excellent! Many thanks for the detailed report.

Edward