@Sergey Avseyev I've granted github access to you (github.com/MarcWeber/vim-git-wiki). Syncing with the web frontend is only done once every 10min. See contributing page: http://vim-wiki.mawercer.de/wiki//this-wiki/contributing.html
> C may be the wrong tool, if you wanted to start a brand-new editor > from scratch. > But re-implementing Vim from the ground up would be a terrible idea. What about allowing Vim to be used in HTML/JS? Is compiling C to JS the best way to go simulating terminal emulators? Do we really need all features which are in Vim? Some features are limiting (eg the gf feature, I already reimplemented it in a script anyway, because I also want to be able to create new files) Also I don't think it would be easy to add features such as "collaborative editing" - if you would rewrite Vim - it would be easier to add such. So it depends on what you want in the end. > Literally decades of work has gone into Vim. Coding C does take decades more effort than something else, sry.rc And the future is longer than history. But I agree that we should know why such a rewrite should happen, and which goals to achieve. > Some thoughts on complete rewrites, where it is called the "single > worst strategic mistake" you can make in developing software: > http://www.joelonsoftware.com/articles/fog0000000069.html There are also voices telling "always write from scratch, never try to fix". In fact the page even says so, too :-) quote: "It’s harder to read code than to write it." If its easier, why not do it (kidding). Also I totally agree that it does not make sense to rewrite Vim in C. I have no answers yet about: What would change if we could share code with Yi,Emacs,JEdit,Vim,.. ? I've been working on snipmate, ultisnips, for days, and some problems just cannot be solved proberly at the moment (eg debugging, async, ..) without running some risk. (Hacks happens to work well enough to be productive ..) > I'd be all for refactoring or rewriting large portions of Vim. But we > need to do it one piece at a time. Doing something like abandoning C > and trying to port all functionality to C++ would be a gigantic waste > of time that will only hurt Vim in the end. That's why I'd like to explore whether it does make sense to write a new language which can be used alongside with C, but also has much more features. But that alone would take weeks to month. Because its not only Vim having such an issue. I also think about gtk,gimp,... Anyway, the wiki does exist to keep memos about what could be done in what way - thus even if we start improving Vim the way it is - it is a starting point IMHO. > If I recall, Bram was not interested in pulling updates from a > separate repository for runtime. So the idea kind of died before it > really started. It could be used to test and prepare patches. But in the end - Vim is (almost) stable, so things work. Adding new plugins is easy. Changing runtime will cause a lot of issues to a lot of people who cannot update it easily - unless they start using ~/.vim/runtime. Eventually we could introduce such special directory and ask Vim to use that if it existst instead of the globally installed one - this would be somewhat compatible ? Does this make sense? Marc Weber -- -- You received this message from the "vim_dev" 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_dev" 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.
