IPC between Leo & vim, emacs, etc

[Edward K. Ream]

This sketch shows my present thinking about how to better integrate Leo with external programs such as vim, emacs or even browsers:

The left side shows a separate program, say vim.  The right side shows Leo, with the body pane hidden because vim becomes Leo's de-facto body.

In Leo: Pressing <return> in the outline transfers control to vim, showing c.p.b with the cursor in the proper place.

In Vim: `:leo` transfers control to Leo, updating c.p.b and putting focus in the outline.

Similarly, in emacs, <Alt-X>leo.

This would let Leonistas to use the real vim (or neovim, or emacs) for text editing.

Discussion

The diagram implies that both Leo and vim/whatever are usually handling keystrokes as usual.  This ensures native speed in the external program.

To make this work, we (only) need some kind of client-server interaction, so that Leo and vim can activate each other without using Alt-Tab.

This will be the focus of my playful prototypes when I return from vacation.  Using yoton is an option, because neovim supports python. A simpler client-server scheme might suffice. And would be necessary with emacs.

Your comments, please.

Edward

P. S. Relevant vim-related issues:

- #990: Embed neovim into Leo.

- #981: Editing in an external editor.

- #559: vim-open-node positions cursor at the last line.

- #313: vim-open-node opens file instead of a node.

EKR

[gar]

Edward, but does Leo need these hard to implement features?

What would Leo achieve when it get them? 

Don't you think that say improving usability is more preferable then another compatibility mode?

Learning curve of Leo is very very steep, it took me more than 2 weeks of reading and experimenting - and I am still cannot work fluently in it.

Trying to customize UI is a severe pain.

Plenty of documented features (like vim mode) do not work as described.

Leo have too many features which become broken right in the next release. 

Is there any reason to add another one?

(I bag my pardon if i was rude - I didnt want to, I just wanted to focus your attention on such simple things like user friendliness)

вторник, 25 июня 2019 г., 14:35:05 UTC+3 пользователь Edward K. Ream написал:

[Edward K. Ream]

On Tue, Jun 25, 2019 at 7:08 AM gar <gar...@gmail.com> wrote:

Edward, but does Leo need these hard to implement features?

No. Leo could be said to be "perfect", just the way it is :-)

What would Leo achieve when it get them?

vim and emacs users who want Leonine features while retaining features of vim and emacs.

Don't you think that say improving usability is more preferable then another compatibility mode?

The picture is a way to avoid vim mode.  It attempts to get the best of vim editing (in vim) with Leonine features.

Learning curve of Leo is very very steep, it took me more than 2 weeks of reading and experimenting - and I am still cannot work fluently in it.

Trying to customize UI is a severe pain.

Are you referring to Leo's themes?  In any case, this is a completely separate issue.

Plenty of documented features (like vim mode) do not work as described.

That's why I am considering removing vim mode.

Leo have too many features which become broken right in the next release. 

I am not aware of any significant bugs in Leo 6.0. 

Is there any reason to add another one?

All enhancements come with costs and benefits.  Imo, there could be important benefits to better cooperation between Leo and vim or emacs.

Summary

Closer integration between Leo and external programs such as vim and emacs might solve existing problems with a minimum of new code.  In any case, the vim plugin needs work.

Edward

[jkn]

Aren't there some ... systems where you can provide (terminology showing the vintage here) a handle to an outside program, of 'the window under consideration'?

To my mind it would be nicer to have the body pane of Leo visible, but actually *be* the vim, emacs or whatever buffer.

In your diagram,I'm not clear how you would send the tree to the external editor. Wouldn't that have to be in text mode, with much potential loss of information?

Just a bit of musing ... I would be interested to learn how other systems do this.

[Edward K. Ream]

On Tue, Jun 25, 2019 at 8:18 AM jkn <jkn...@nicorp.f9.co.uk> wrote:

Aren't there some ... systems where you can provide (terminology showing the vintage here) a handle to an outside program, of 'the window under consideration'?

Sure.  nvim supports servername.  See also nvr.

To my mind it would be nicer to have the body pane of Leo visible, but actually *be* the vim, emacs or whatever buffer.

Sure.  Alas, I know of no way of doing it.  On any platform.

You could call this a holy grail. Imo, it's not likely to happen.

In your diagram,I'm not clear how you would send the tree to the external editor. Wouldn't that have to be in text mode, with much potential loss of information?

The diagram implies no such thing.  The tree is in Leo.  You would have to move back to Leo to move from node to node.

You could imagine, say,  `:leo-up` and similar commands that would simulate an up arrow in Leo's outline pane, updating the body pane (that is, vim) in the process.

I expect to play with these ideas in prototypes.

Edward

[Edward K. Ream]

On Tuesday, June 25, 2019 at 9:41:57 AM UTC-5, Edward K. Ream wrote:

On Tue, Jun 25, 2019 at 8:18 AM jkn <jkn...@nicorp.f9.co.uk> wrote:

To my mind it would be nicer to have the body pane of Leo visible, but actually *be* the vim, emacs or whatever buffer.

Sure.  Alas, I know of no way of doing it.  On any platform.

Btw, even if Leo's body pane were vim, IPC would still be needed between Leo and vim.

Edward

[Matt Wilkie]

Btw, even if Leo's body pane were vim, IPC would still be needed between Leo and vim.

This sentence made me wonder: how is IPC or it's analog different from what's used within Leo: from outline to body, from Altix (Alt-x) to outline, from body to Render, etc.? Every 'dock' a module which could also be an external program.

-matt

[Edward K. Ream]

On Tue, Jul 9, 2019 at 12:20 AM Matt Wilkie <map...@gmail.com> wrote:

Btw, even if Leo's body pane were vim, IPC would still be needed between Leo and vim.

This sentence made me wonder: how is IPC or it's analog different from what's used within Leo: from outline to body, from Altix (Alt-x) to outline, from body to Render, etc.? Every 'dock' a module which could also be an external program.

The "I" in IPC stands for "inter", not "intra".  Leo "communicates" between panes using python function calls and/or Qt signals.  It would be better to use more Qt signals, but as far as IPC goes the details don't matter.

Edward