Free-floating Body Editor Windows?

[tbp1...@gmail.com]

Leo can have more than one body editor open at a time.  Though it can get confusing about which node is in which window, this can be useful.

I now have a case where it would be useful to have several free-floating body editor windows open at the same time.  They should be resizable and independently closable.  I'm wondering if this capability would be feasible to add.

[Edward K. Ream]

On Sun, May 23, 2021 at 9:36 AM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

I now have a case where it would be useful to have several free-floating body editor windows open at the same time.  They should be resizable and independently closable.  I'm wondering if this capability would be feasible to add.

Everything is possible, but it may not be easy.

In this case, however, the Easter Egg interface (right-clicking Leo's splitters) provides a relatively simple way.

Edward

[gar]

By my opinion second editor's buffer in leo is quite useless. It cannot be moved to another location or resized.

I tried to use it as a small FIXME-window - but failed because of it's immobility.

[tbp1...@gmail.com]

Well, yes but then not really.  When I invoke Open Window  from the splitter popup menu, the body editor does show up in a floating window.  But now there is no body pane in the main Leo window.  If I add a new body editor, it opens in the same floating windows as the first one.  There are times when I'd like to be able to move various body editors around independently. The font size is smaller, too.  Then if I want to go back to my initial layout, it's baffling to understand how to do it with the splitter menu - unless I had first thought to save a named layout the way I like it.

And some of those splitter context menu operations caused Leo to crash with a message that the parent splitter doesn't exist anymore (sorry, I don't know just how to reproduce these crashes;  I can work it out if it will be helpful).

So yes, I can kind of open floating editors, but it's been painful.  Really, what I am thinking of works like this:

- I open a floating editor.  The editing pane in the main Leo window continues to exist there.  

- I open a second floating editor.  It opens in a new window, and I can move and resize it independently.

- I can open more floating editors the same way.

- I can close all the floating editors with a single command.

For the last bullet, I suspect that if I restore a named layout that does not include the floating panes, they would go away.  That would be quite acceptable.

In the meantime, I'll see how I like working with multiple editors in a single floating window.
 

[Edward K. Ream]

On Mon, May 24, 2021 at 10:07 AM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

Well, yes but then not really.  When I invoke Open Window  from the splitter popup menu, the body editor does show up in a floating window.  But now there is no body pane in the main Leo window.  If I add a new body editor, it opens in the same floating windows as the first one. 

I wasn't clear. The Easter Egg interface could be extended to do what you want.

Edward

[tbp1...@gmail.com]

Turns out that edit-pane-test-open is almost there.  I have to make about three configuration changes using the configuration menu - for each pane I open - then it's about what I had in mind.  That's too cumbersome for routine use, but perhaps with some quality time studying the code ...

BTW, do we know if anyone actually uses this edit-pane thing?  It's got all those good-sounding options, like editpane/markdownview.py, but VR3 does most of them and with better rendering (IMHO) and more functionality.  It looks experimental, like it was used to learn how to do what the author actually wanted to do. So maybe it's no longer useful to anyone else. I might want to tinker with it, but not if it's actually used.

[Edward K. Ream]

On Mon, May 24, 2021 at 11:18 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

Turns out that edit-pane-test-open is almost there. 

Glad to hear it.

BTW, do we know if anyone actually uses this edit-pane thing? 

Like so much else about Leo, there seems to be know way to know until someone complains :-)

Edward

[tbp1...@gmail.com]

I've just written a plugin to open free-floating editor windows that are linked to nodes on a Leo outline.  It's very simple, much simpler than the edit-pane plugin. That's because it does much less.  But it does pretty well just what I wanted.

The plugin has a command that opens a new editing window that is locked to the selected outline node.  If you type into it, the host node's text picks up the changes.  If you type into the host node, the free-floating editor pane picks up the changes.  You can have multiple editing panes open, one per selected node.

The use-case for the plugin comes from the zettel-kasten work from last year.  There was a long but rather fragmented discussion of that last spring: see https://groups.google.com/g/leo-editor/c/TqiNdBfnEig/m/2qAK9XecAgAJ.  The idea is that in a physical zettel-kasten (basically an extensive, cross-referenced set of index cards, each one having a narrowly-focused topic), one would get out a number of related index cards - the zettels - and spread them out so they could all be looked at (and maybe altered) at the same time.

In a tree-like presentation like Leo's, you can't really do that.  You can have several editors in the edit pane and you can make that pane to be free-floating, but they become cumbersome quickly, and don't help you focus your attention on just the bits that you want.  And it's too easy to accidentally change the focus of one of them to the wrong node.

This plugin simulates placing selected cards on a desktop so you can think about them and work on them.  You could even move the cards to a different workspace with no other clutter.

These editor windows are so simple that they don't do any colorizing, but for the intended purpose this wouldn't be needed.  The underlying editor widget implements its own undo functionality (CNTL-Z).  The editor will update the text of the host outline node even if it is out of sight in another workspace (tested on Windows but not yet on Linux).

I haven't asked for this plugin to be merged into Leo yet, but you can get it to play with at my own clone repo:

https://github.com/tbpassin/leo-editor/tree/tbp-freefloat-editor

The plugin is the leo/plugins/freewin.py file in the tbp-freefloat-editor branch.  To use it, copy the file to Leo's plugins directory,  add it to the list of enabled plugins in MyLeoSettings.py, and restart Leo.  Select a node to work with, and run the command named z-open-win.

[Edward K. Ream]

On Fri, May 28, 2021 at 1:18 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

I haven't asked for this plugin to be merged into Leo yet

Feel free to create a PR. Plugins merely need be not actively dangerous :-)

Edward

[tbp1...@gmail.com]

Thanks.  I'll be doing some more testing first, though.

[tbp1...@gmail.com]

I have revised and fixed some bugs.  The free-floating viewing window can now render Restructured Text as well as show an editing pane.  This can be useful if your node contains RsT (as some of mine do).  If you open a new window linked to a particular node (A), then navigate to a different node (B), and then do some editing in your window for node A, you will see those changes back in the standard Leo edit pane when you select Node A again.  And if you edit node A while the free-floating window is showing the RsT rendered view, your changes will be rendered in the rendered view as you type in the outline.

I actually found these windows to be very helpful as I was revising the code.  I prototyped the changes in a different outline.  Then I opened several free-floating windows on the prototype code.  This made it easy to see and understand the differences, and I could copy parts of the prototype to the right places in the original outline.  Dog-fooding, it's wonderful!

I have attached a screen shot.  The two editor windows on the right show 1) one node of the prototype code, and 2) the corresponding - but not identical - node of the plugin's code.  The "Settings and Configuration" window is a rendering of the RsT on a node on Viewrendered3's docstring.

This version is marked as 1.0b4.  It is currently on my Leo clone at

https://github.com/tbpassin/leo-editor/tree/tbp-freefloat-editor

The branch is tbp-freefloat-editor, and the plugin file is named freewin.py.  The one and only new command added to Leo is z-open-win.
If I don't find any bugs, and if no one makes any comments in the near future, I will create a PR for it.

[tbp1...@gmail.com]

I have fixed some bugs when switching between the editor and RsT views. I also have made it possible to optionally use a custom css  stylesheet for each view.  The name of the invocation command is changed to z-open-freewin.  I have added an extensive docstring that contains instructions about how to use the optional css stylesheets.  The version number is now 1.0b6.

Please give this Freewin plugin a try and let me know how it works for you.  It is on my repo at

https://github.com/tbpassin/leo-editor/tree/tbp-freefloat-editor

This URL points directly to the tbp-freefloat-editor branch.  The file is at leo/plugins/freewin.py.

[gar]

Hey! Thanks for your work, it's very much appreciated. I was missing such a function in Leo for a long time. 

And a question related to this is: can then your plugin be used to integrate say tree from parsed output of ctags for current file?

This is another thing I miss very much (sure after vim  editing).

[tbp1...@gmail.com]

Thanks for your interest!  I am not sure what you are asking for.  In fact, I'm not sure what the "ctags" are.  The intent of the plugin is to focus on a single node.  The plugin maintains a reference to the commander of its underlying node, so almost anything would be possible in principle.   It would be easy enough to provide another view in addition to the editor and RsT views it has now.

As usual, the challenge would be to make the new view simple to use and clean in its appearance.  It would be better if it did not try to change the outline, at least not beyond the underlying node.  That's because you might be viewing at one place but end up making changes somewhere else that is not in sight.  Also, you don't want to get into a cycle of changes to the outline triggering a "changed" event in the Freewin window, which then triggers a new changed event back in the outline ...

I would also prefer to keep the plugin's code simple.  Right now it is about as simple as it could possibly be.

But probably most anything can be done if we can get clear on what it would be.

[tbp1...@gmail.com]

I looked up ctags so I have some idea about them now.  @gar, how do you picture their use?  There are a couple of existing Leo plugins that use ctags files.  Personally, the functionality like that I use the most is Leo's ability to jump to method defs.  I don't know how that's accomplished but it's a great feature of Leo.  I have thought of trying to get that capability into this Freewin plugin. The way I see it working is that you CNTL-click on a method invocation and a new Freewin window opens up for the node where the definition is.

This would be way beyond the scope I had in mind originally, but it does seem like it could be delightfully useful.  I'm not sure how tricky it would be to implement.  If that is what you were thinking of, I could look into it.

The thing is that I didn't devise these editing windows with programming in mind.  I mostly wanted to view so-called "zettelkasten" notecards - that is, small focused chunks of textual data.  So the windows don't do any syntax colorizing, and the way they are constructed I don't think that adding colorizing to the editing view would be very easy at all.  Another thing I could look into ...

[gar]

Hello!

My story is that I was trying to use LEO for my pet js project. Until it was small - I could easily navigate the code and jump to methods with SEARCH. Clones worked fine with textual projects but I failed to involve them into programming activities. So after some time LEO become for me just a programming notepad with some funny features. 

Some more time elapsed and then I discovered that my code become ugly and dirty. File for several thousands of lines of code, strange function names. This is was a consequence of the LEO's features: when your organize code with sections (like LEO's nodes) and navigate with search only - you dont see your code and it become's like LEO's code itself (take a look into original source in a plain text editor - and you'll get surprised: it's not maintainable w/o LEO).

Then I decided to move my project to VIM and made a huge refactoring (actually beautifying) of all - so it can be possible to show the code to another person w/o shame. Since then I dont use LEO for programming and use it only for tasks where it is brilliant - textual, planning, ideas, brain storming.

And in parrallel I was thinking - what should I get in LEO to return (implicitely - my code must be same clean and pretty as it is in VIM). And think that those things are:

- I need to see the overall picture of the file. Since in node I even dont know which _real_ line of code I edit - I loose any feedback from the code and operate only with nodes, which itself leads to ugliness. Here method's map can help. In VIM I get it with CTAGS and language servers.

- I need a simple method to navigate the project. Say I press ctrl-] - and go to the place where the method under the cursor is defined. Search also works, but when you operate nodes - this leads to strange side effects in my particular case. Also I need ctrl-o to move back to the place I navigated from. Yes, I need navigation history! I wrote a bunch of my own ugly commands for that - but they do it not exactly in the way other IDEs do. This feature also can be implemented with CTAGS or with language server.

Actually in advance - not too much. And both features can be scripted with help of ctags - since it's very simple to integrate: one must call it periodically and parse the output.

But... Where to place the result? We can make another tree (haha no), or run into development of another gui control. I was trying to implement a simple ui hack for highlighting a word under the cursor - it surprisingly has been pretty hard, I cannot spend that much time for that. So currently it's easier to use VIM. But I still hope that I'll find the way to get what I want w/o much GUIing.

Your work looked reasonably suitable for that, so I asked.

Thanks for the interest. Hope your were not too bored reading this :-)

вс, 6 июн. 2021 г. в 23:48, tbp1...@gmail.com <tbp1...@gmail.com>:

[tbp1...@gmail.com]

On Monday, June 7, 2021 at 3:02:36 AM UTC-4 gar wrote:

when your organize code with sections (like LEO's nodes) and navigate with search only - you dont see your code and it become's like LEO's code itself (take a look into original source in a plain text editor - and you'll get surprised: it's not maintainable w/o LEO).

This can be a real problem, all right.  But it's not all bad.  There is a lot of advice out there to make function/method bodies only one screen long.  This can lead to creating a lot of functions just for the purpose of breaking up the code.  For each one, you have to pass parameters, often many, or use global parameters (or at least, global to the module or unit you are working in).  With Leo at least you can break up the code into screen-sized chunks without being forced to create function calls that would not be needed otherwise.

But

 | so it can be possible to show the code to another person w/o shame. 

Yes, that can be a real problem. when the other person doesn't use Leo.  At the very least, you would need to save as @clean instead of @file.  I have not brought one of my (professional) projects into Leo just for that reason.  OTOH, a big project in, let's say, Visual Studio, is basically unusable by someone who only uses Eclipse, and vice-versa.  It's just that many more people use those tools than use Leo.

And in parrallel I was thinking - what should I get in LEO to return (implicitely - my code must be same clean and pretty as it is in VIM). And think that those things are:

- I need to see the overall picture of the file. Since in node I even dont know which _real_ line of code I edit - I loose any feedback from the code and operate only with nodes, which itself leads to ugliness.

I don't seem to feel this particular problem.  Even using a normal text editor, say, with different files open in different tabs, I don't really know where things are in a bigger project.  I get more help than hindrance from Leo's node structure.  Anyway, with some discipline one could follow a one node-one function rule and then the organization would be like it would be with some other IDE.

 

Here method's map can help. In VIM I get it with CTAGS and language servers.

- I need a simple method to navigate the project. Say I press ctrl-] - and go to the place where the method under the cursor is defined.

Leo has CTRL-CLICK for the same purpose.  If it were an ordinary command it could be linked to a hotkey so the mouse wouldn't be needed.  But so far I haven't been able to find it in the code base. possibly because I haven't thought of the right search phrase.  If @Edward is reading this, maybe he would point me to it.  So Leo itself doesn't seem to need ctags, since somehow it is doing that job for itself already.

 

Search also works, but when you operate nodes - this leads to strange side effects in my particular case. Also I need ctrl-o to move back to the place I navigated from. Yes, I need navigation history! I wrote a bunch of my own ugly commands for that - but they do it not exactly in the way other IDEs do. This feature also can be implemented with CTAGS or with language server.

Leo has those forward-backward arrow buttons for navigation history.  I use them a lot.  I presume they could be bound to hot keys.  Otherwise, I bind a hot key (F4) to move to the next marked node.  I use that a lot.  I bind F9 to set a mark.  I borrowed the F9/F4 from Editplus, where I found they were a major help.  (I use F10 to clear all marks.)  Actually, EditPlus uses F9 to toggle a mark, not just to set it, and I think that's more useful.  Maybe I will look at writing a small command to do that.

 

But I still hope that I'll find the way to get what I want w/o much GUIing.

Your work looked reasonably suitable for that, so I asked.

I created the Freewin plugin so that I could continue to look at the content of several nodes at the same time while I navigated away from them in the tree. with the editing ability thrown in as a bonus.  An extra benefit is that you get a clean view of a node's content with minimal distractions.  But the viewing window is not a real Leo body editor.  I don't know if one could open one of those in a free-floating window - not the current free-splitter arrangement, that doesn't do what I want.  If that were possible, then you would presumably get all of the body pane's features without any extra work.  That plus some well-selected hot key bindings would get you most of the way, perhaps.

 

Thanks for the interest. Hope your were not too bored reading this :-)

:) 

[gar]

Thanks for all your advices, actually I tried almost all of them. But each of them has a counter-argument from my side. I dont want to flood about cons and pros here, but LEO doesnt suite well.

LEO operates more or less (well, rather less) well on python code, all the other languages have a poor support. You can do a few with javascript (even syntax highlighting rules are outdated, I had to write my own), not saying about C++. 

I know about @files and etc, I used mark too in the same way you do, and so on so so on. But at the code base of about 10 KLOCs it stops to work and you have to move out.

So as I understand your free layout is pretty useless for my needs. Ok. Sad but true. And thank you for the discussion.

[Edward K. Ream]

On Monday, June 7, 2021 at 2:02:36 AM UTC-5 gar wrote:

> when your organize code with sections (like LEO's nodes) and navigate with search only - you don't see your code and it becomes like LEO's code itself (take a look into original source in a plain text editor - and you'll get surprised: it's not maintainable w/o LEO).

Thanks for these comments. @clean can help, but perhaps not as much as we all would like.

The upcoming "Leo for vs-code" plugin (the leoInteg project) is likely to solve most of the problems you mention. Vs-code will give you the typical/traditional view of all external files, while the "Leo for vs-code" plugin will give you the Leonine view.

Edward

[gar]

Hello Edward!

Thanks for these comments. @clean can help, but perhaps not as much as we all would like.

Another pain of using LEO as a replacement of IDE is that all the code you store in @clean is duplicated, which pollutes git alot.

So I still dont know what is more evil - @file or @clean.

 

The upcoming "Leo for vs-code" plugin (the leoInteg project) is likely to solve most of the problems you mention. Vs-code will give you the typical/traditional view of all external files, while the "Leo for vs-code" plugin will give you the Leonine view.

Actually I love original LEO's gui, even it has some very major disadvantages, and would be missing it.

But also I understand that it becomes very painfull to implement new modern features for it.

So waiting vscode plugin with hope.

[Edward K. Ream]

On Mon, Jun 7, 2021 at 4:20 PM gar <gar...@gmail.com> wrote:

The upcoming "Leo for vs-code" plugin (the leoInteg project) is likely to solve most of the problems you mention. Vs-code will give you the typical/traditional view of all external files, while the "Leo for vs-code" plugin will give you the Leonine view.

Actually I love original LEO's gui, even it has some very major disadvantages, and would be missing it.

But also I understand that it becomes very painfull to implement new modern features for it.

So waiting vscode plugin with hope.

The vs-code plugin creates a window very similar to Leo's main window. All of Leos commands (that make sense in vs-code) will exist.

Edward