> 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
