Re: improving Vim - Kickstarter - brainstorming - goals - who wants to join?

> irc: Have you seen my mail
Please don't expect me to reply within 1h. 24 to 48h should must be
enough :)

> - Client-server model from the core, following tmux ideas regarding
> sessions/windows.
You think its enough to say "client-server" model? Please try this:

client-server model for these use cases:
- ..
- ..
- ..

> - Small core written in C.
No way. C is a risk. In industry even the "C" kernel gets rewritten
using newer technologies. If you want to go that route without me.

I agree that "C" should be one way to compile the editor for portability
reasons which is why I think C++11 or something compliing down to C is
the perfect tool. But that's research (my TODO item)

> but C is a very simple language that anyone can learn
I'm not interested in languages "anybody can learn" to reinvent each
wheel yet another time. There are facts, and those are that you're 5-10
times slower writing an app in C compared to high level languages for
various reasons. And those arguments are stronger IMHO.

> - Editor server state(which should be sessions, windows, and buffers)
> - API that plugins can use to control the editor state.
> - Loading plugins
> - Emitting events from the client to the plugins and back to the client.
> - API for system tasks like dealing with files(?)
Try to find particular use cases. In the end there must be one decision:
Keep improving Vim or start from scratch. Starting from scratch will
take a couple of years (See yzis history, jedit, ..)

> - Handle concurrency/multitasking using event loops which is more
> efficient and simple than threading.
I don't think that "comping up with event loops" is a design yet.
If you want such join Yi, so that we can find out whether even
improving Yi (eg making it understand VimL) could be a possible
upstream. Haskell already has most of what you're asking for:
Simple event loops, typing, cheap threads etc.

Eg what about concurrent editing?

> libuv
I've added this to be evaluated. I don't know it yet.

> - Extreme extensibility based on editor events. Everything that can be a plugin,
> should be a plugin.
So this means "break" and rewrite?

> - UI independent. This is a direct consequence of the client/server model.
Yes, but why stick to C then? Why not be independent of target "JS in
browser vs console vs gtk/qt/.." ?

> motivation is simple: Longevity.
That's why I even think about "invent a new language" so that code can
be shared between Emacs/Vim/Yi. Eg write code which can be compiled down
to C (which could be used by Vim then), but share dev work with other
editors. That would allow some upstream for Vim, and still allow to
write a new core, too.

I agree on this. Being modular is key.

> Who can be sure if in the future we will be
> using keyboard/mouse to write programs?
Right, .. I agree. Its me who would like to replace keyboard/ mouse.
Eg see "plover stenoknight" as exampl, but that design dates back very
much, too. I know there are many alteranatives. (Yet I don't use 2
keyboard /mice input system for my pc) - why? Because when I tried and
typed something into a firefox address bar a "completion popup happens",
and focus was assigne randomly to the other keyboard.
That all can be fixed - but who is going to do all the work ? ..
Just to give you an idea what kind of "new issues" can happen.
That's why C is no option, because you there is not enough abstraction.
No way. It can only be a target IMHO.

> As some may have noticed, the above doesn't necessarily describe a text
> editor, but a generic framework for building any kind of editor or IDE.
Well - something which could be turned into IDEA/Eclipse/... etc ?
Not doable in a couple of years.

Marc Weber

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.