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/CAC%2B8SVyiXQZRuP-eu%2BUNPWb%2BoqNsS0ahWuW3oueM9mr4NYKkBA%40mail.gmail.com.

Reply via email to