On 16/01/14 17:56, Marc Weber wrote:
@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
I don't know if it makes sense, but if you want to maintain separately a
full collection of Vim runtime files, you could always set $VIMRUNTIME
to somewhere else than where the install process puts it. Not that I see
much sense in it though, to my mind it seems more convenient to have the
distributed $VIMRUNTIME for most scripts, and add $VIM/vimfiles/ and/or
~/.vim/ (or %HOME%\vimfiles\), plus their after/ subdirectories, for
additions installed from elsewhere or developed locally.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
67. Your hard drive crashes. You haven't logged in for two hours. You start
to twitch. You pick up the phone and manually dial your ISP's access
number. You try to hum to communicate with the modem. You succeed.
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
