> Since we're talking about this, I have a somewhat related question..
>
> If backwards compatibility was not an issue at all, what would be
> changed in vim?
But, backwards compalitibility will always be an issue. One of the
strengths of Vim is the plethora of ready-made plugin solutions to a
wide variety of problems.
> How many people would prefer it if at some point
> there was a significant break from current codebase and vimL would
> be changed to something similar to ruby or python, even if that
> broke ALL currently available scripts,
One of the biggest strengths of VimL, and probably the main reason for
its continued existence, is that most of the language is made up
of :ex commands which you can/do use in your normal interactions with
the editor. Learning VimL is mostly equivalent to learning to use Vim
itself.
For this reason, I think it would be a really bad idea to make
significant changes to VimL for the sake of making it look more like
another language.
I would certainly not be opposed to making changes to the Perl,
python, Ruby, etc. interfaces where they are lacking, for example it
would be nice to be able to pass complex variables back and forth
between Vim and the scripting language being used.
> maybe there was a split into
> separate terminal and gui versions that would share some libraries.
What would be the point of this? I disagree with making changes for
the sake of making changes.
> I think I'd be in favor of all of that even though I realize it
> won't happen.
>
> But it's interesting to discuss which things are being kept because
> people use them and like them and what's being kept exclusively for
> backwards compatibility.
>
> Sorry if this was discussed to death before, I don't think I've
> seen this raised and quick googling turns up nothing.
>
> -ak
--
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
No comments:
Post a Comment