On Mon, Dec 2, 2013 at 3:55 PM, Marc Weber <marco-oweber@gmx.de> wrote:
> You think its enough to say "client-server" model? Please try this:
>
> client-server model for these use cases:
> - ..
> - ..
> - ..
- Multiple clients connected to the same vim instance would provide an easy way
to have collaborative editing(like pair programming).
- Vim running in a remote server with local GUI, without the security
implications of X forwarding
- Use vim as a terminal multiplexer for detaching from a remote server without
closing the running programs.
- This is actually a very particular use case of mine, but it should illustrate
another scenario were it would be useful: I do all my development work inside
a headless linux VM running in virtual box in a windows laptop. Having a
client/server architecture would let me detach a windows-native client, save
the VM state and restore everything later even across reboots. This is already
how I work, except that I use a combination of TMUX, vcxsrv(windows
port of xorg), urxvt and terminal vim. This would let me replace all those
programs by vim.
>> - 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.
Like I said, I'm not particularly fond of C either, but consider the following
points:
- You wont be reinventing the wheel very much because the C core will not be
modified very often. Most of the development will be done in scripting
languages.
- C will force you to keep the core program very small and clean. If you use
C++ you will end up writing a lot of functionality in it,
functionality which
should be written as a plugin in a higher level language like python.
- Most of the functionality will be implemented as plugins in third party
languages, choosing C will give the editor easy interoperability with any
language you can think, improving the chances of having bigger communities.
Of course, thats just my personal view on the matter, I would have no problem in
using another language for writing the core editor.
>> - 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?
Event loops simpler because theres no need for locking or synchronization.
Take TMUX as an example:
its server can talk to hundreds of programs simultaneously in a single thread
and is very efficient in doing so. I'm not sure what you mean by concurrent
editing but that would be no problem for an event loop since any kind of
concurrency problem can be modeled on top of it.
>> - 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/.." ?
I suggested C only for the core/plugin loading which would be very small.
Nothing would stop one from writing a websocket plugin and have a
javascript/browser client talk to it.
>> 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 think it would be extremely challening writing an editor extension language
independent of the editor.
>
> 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.
Anyway, thanks for the feedback.
My goal with the proposed design is simple: Combine VIM and TMUX into one
program, removing overlapping features and moving every possible feature to
plugins. And by "every possible feature" I mean even things such as terminal
emulation, so vim core would not be cluttered with terminal emulator stuff.
But lets abandon crazy rewrite ideas that would take too long to complete and
focus on a feature that would greatly improve VIM IDE capabilities.
Consider that VIM could run multiple background jobs simultaneously and perform
asynchronous UI updates(without using CursorHold hacks). Here are some things
this would enable:
- Run terminals in buffers with full vimL(and other languages) scripting
support.
- Powerful asynchronous code completion/analisys tools could run as
background processes without slowing down the UI(YouCompleteMe is an example
of such an engine).
- A background job could constantly regenerate tags when a file is changed,
notifying vim for updating plugins such as tagbar.
- Plugins such as CtrlP would not block when calculating big datasets.
- Vim could be extended in any language imaginable(even non-embedable
platforms just as node.js) by providing something like a RESTFUL extension
API. Extensions could do extensive background work without affecting vim's
lightning fast speed.
Since one could script terminals and background processes from withing vim, the
possibilities would be endless.
So concurrency support is a feature that would greatly benefit vim. I havent
ever looked into vim source code, but I believe the best approach to adding
concurrency would be through an event loop library like libuv, as it wouldn't
require adding locks or syncronization to current code. Could a vim developer
give some feedback on this idea? Depending on the answer I could feel motivated
to dig into VIM's source code and provide patches for these changes.
Thiago
--
--
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.
No comments:
Post a Comment