I think you are looking at the wrong level. You are writing in terms of implementation, but what is ti 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. On Thursday, April 9, 2020 at 7:06:49 AM UTC-4, gar wrote: > > 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. > > No, it's not great. Any ideas would be appreciated. >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/48fabfab-1bd4-4932-879b-eb4d76878045%40googlegroups.com.
