No vim or pyzo bridges for Leo

[Edward K. Ream]

I have closed the following issues and marked them "Won'tDo":

#1235 (neovim)

#1384 (pyzo)

Imo, bridges between vim or pyzo make no sense.

Consider a simple thought experiment. Let's imagine that we did have a bridge between Leo and either vim or pyzo. Then what? Neither vim nor pyzo could be made to understand Leo, and Leo would in no way benefit from the bridge.

Instead, I encourage users to use vim and pyzo in addition to Leo.

Edward

[Edward K. Ream]

On Tue, Apr 7, 2020 at 5:16 AM Edward K. Ream wrote:

Imo, bridges between vim or pyzo make no sense.

Otoh, the VR3 plugin is the best kind of bridge.

Edward

[gar]

Well strange to hear it from you.

Actually Leo panes are vim's buffers. And all of them can be directly mapped one to another. Like some IDE plugins for vim do.

For the most of programming jobs now done with Leo I do not need Leo GUI and actually would like to avoid it if I could.

I can setup vim buffers as I need, I can run vim via ssh in tmux, I can, I can.... But I cannot cause I fall in love with leo's approach.

So I do continue to use Leo GUI which is hard to configure, slow and need to be restarted for every little tweak.

I have to use very outdated syntax highlight schemes for most languages I use! pygments are claimed to be supported

but works with python only.

I will never have plenty of those sexy editing plugins and would always use ms word editing style with alot of mouse.

With Leo GUI I even cannot run leo on 32bit linux cause PyQt does not support it. And what if Qt change license more drastically?

Also there are many vim enthusiasts which like to make plugins for 3rd party goodies. But for leo it's not possible for now since it is too closed.

The same with emacs I believe.

I could write more arguments but stop here cause english is not my native language and I am tired :-) But hope I told enough to be my voice

taken into account.

вт, 7 апр. 2020 г. в 13:16, Edward K. Ream <edre...@gmail.com>:

--
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 leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/72fe6818-76d2-4242-b97f-e87417b54696%40googlegroups.com.

[Thomas Passin]

Hi, Gar,

On Wednesday, April 8, 2020 at 11:58:27 AM UTC-4, gar wrote:

I have to use very outdated syntax highlight schemes for most languages I use! pygments are claimed to be supported

but works with python only.

Colorizing works with other languages if you mark them with an @language directive, like this:

@language java

import javax.servlet.*;

public class Experiment extends javax.servlet.http.HttpServlet {
    static Logger logger = Logger.getLogger("org.exp.Codes");
    boolean _DEBUG = false;
    String _FORMAT = "atom";
    String _MIMETYPE = "application/xml";
    String _TEXTTYPE = "text/plain";
    String _JSONTYPE = "application/json";

Paste the snippet into a Leo code.  It should be colorized.  It is on my system.

I realize that colorizing is just a small part of your post; I'm not addressing anything else here.

[Edward K. Ream]

On Wed, Apr 8, 2020 at 10:58 AM gar <gar...@gmail.com> wrote:

Well strange to hear it from you.

Actually Leo panes are vim's buffers. And all of them can be directly mapped one to another. Like some IDE plugins for vim do.

Yes, I understand that. Let me try to explain what I think the problem is.

Suppose we had a bridge between neovim and Leo. That bridge would be a neovim plugin, presumably written in python. Actually, the details don't matter.

Well, what would the bridge do? My guess is that Leo would intercept keystrokes (in Leo's body) and send them across the link to neovim, which would then update vim's buffer and send (somehow) the results back to Leo, which would then update Leo's body pane.

That's a lot of work to do on each key stroke!

Furthermore, Leo's environment is a lot more complex than neovim's. So some keystrokes can't be sent to neovim, because they mean something to Leo.

So I do continue to use Leo GUI which is hard to configure, slow and need to be restarted for every little tweak.

I suspect that the bridge scheme described above will be slower.

I have to use very outdated syntax highlight schemes for most languages I use! pygments are claimed to be supported but works with python only.

Updating Leo's syntax coloring probably is a separate issue.

Also there are many vim enthusiasts which like to make plugins for 3rd party goodies. But for leo it's not possible for now since it is too closed.

The "Won'tDo" label means that I won't do it. Any Leo user is welcome to create their own plugin.

The same with emacs I believe.

Leo already supports the pymacs bridge. Any emacs guru is welcome to create another kind of emacs bridge. Again, I am not going to do that, but I would welcome contributions.

I could write more arguments but stop here cause english is not my native language and I am tired :-) But hope I told enough to be my voice taken into account.

You have explained yourself very well. If you have ideas for a vim bridge I would be glad to study them.

The main point I am trying to make is that all bridges between Leo and another editor should be done by those who actually use the other environment. If you would like to create a bridge between Leo and neovim I would be happy to help in any way I can.

Edward

[gar]

First, I apologies for being too emotional. I do really love vim and do really love leo so the news that they would never be together made me too upset. 

Secondly, after thinking about the bridge more and more I would probably accept your point of view.

Making the bridge itself has no practical sense. To be connected with other editing environments Leo have to provide virtual GUI which then can use whoever else.

This is very hard task and I dont actually believe it is possible to be done without full redesign and rewrite of the whole code base.

Otherwise every bridge to so anything would be just another portion of mess which would got out of sync with every minor release.

Thank you for this lesson of wisdom, Edward.

[Edward K. Ream]

You're welcome. Btw, I didn't perceive any undo "emotion" in your post.

There is another potential way forward. At present, Leo's vim.py plugin uses vim's client/server interface. Instead, perhaps vim.py could talk to a python plugin on the neovim side, say leo.py.

Edward

[gar]

Well, there's a trouble with it. You have 2 separate windows which are in sync, but you have to remember about it all the time.

And none of your hotkeys work until you press alt-tab.

This is not the route I'd love to use on everyday basis.

[Edward K. Ream]

On Thu, Apr 9, 2020 at 5:04 AM gar <gar...@gmail.com> wrote:

Well, there's a trouble with it. You have 2 separate windows which are in sync, but you have to remember about it all the time.

And none of your hotkeys work until you press alt-tab.

This is not the route I'd love to use on everyday basis.

No, it's not great. Any ideas would be appreciated.

Edward

[gar]

I dont see any other opportunities but to re-design Leo, leave all the features but change all the mechanics.

Let me give an example. Let it be the problem of code navigation.

Far away from the start of the epoch editors did it themselves: parsers, regexps, strange approaches.

I keep remember early KDevelop which implemented most of C++ parsing right in the code of the editor!

What came next? ctags, service on demand. Editor asks to parse the file and get result in some standard format.

This made different editors similar to each other, and choosing one became just a question of taste.

But later another actor came onto the scene: language servers. There became no reason to even ask - you can just take.

Editors and navigation information became absolutely independent. That made all IDEs quite indistinguishable.

Using this example as a basis I'd love to say the following: Leo now at stage 1 and to evolve further more it should jump

into stage 2. There's now ways to evolve inside stage 1 anymore cause this is almost the superior state of it now.

So the problem is not - should Leo communicate with vim or say notepad++ - the problem is: should Leo change it's

architecture without loosing it's features. No matter which answer would be given - vim bridge is not needed.

[Thomas Passin]

I think you are looking at the wrong level.  You are writing in terms of implementation, but what is it about vim that you expect to do in Leo, and why do think Leo has something to offer an experienced vim user?  Note that I'm writing as a non-vim user, so my ideas about its usefulness are vague.

For example, the basic editing scheme, consisting of command and insert modes.  It shouldn't be hard to get  a Leo body editor to work that way.  You would get the benefits of Leo's tree navigation together with the mechanics of vim editing.  But it seems that to get vim to be really useful, one needs to come up with a selection of plugins and configuration that really suits each user.  Bare, as-installed vim isn't enough.

Clearly, Leo isn't going to be able to use vim plugins as is.  But who is going to try to reproduce the functionality of a vim plugin for Leo?  Maybe for one or two, but I don't see it happening for a large part of the vim ecosystem of plugins. 

So if "vim" means "configured vim with plugins", it's just not going to happen in Leo.

OTOH, if you would like to navigate Leo trees but edit nodes with vim, the vim plugin for Leo already does that.  Well, I don't know if it's been updated for Python 3, but if not it presumably could be updated without too much effort.  Maybe it could also be adapted to work with neovim, which seems to be a good plan.

If neither of these options - the vim plugin or a body editor that uses vim-style editing modes - are what you would like, then it is time to explain just what abilities you do have in mind.