>
>
> On Jul 28, 4:23 pm, AK<andrei....@gmail.com> wrote:
>> 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.
I understand, but I thought it's an interesting question to explore
anyway.
>
>> 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.
Well, in python interface you can do something like:
from vim import command as c
def normal(cmd):
c("normal "+cmd)
so commands can be run as
c('bnext')
normal('3jyy')
etc.
I think that's about as easy as using vimL.
But in many ways languages like python and ruby are cleaner and
nicer than vimL.. for example, in python all functions, vars and
classes are in module's namespace, not global, so if you need
to use it you can do
import mymodule
mymodule.myfunc()
and not worry about name clashes.
putting vars into strings is much cleaner:
exec 'let ' . a:var . ' = ' . "'" . a:value . "'"
cmd = "let %s = '%s'" % (var, value)
What's easier to read? And that's just 2 vars..
Function args are very powerful and easy to use:
def myfunc(x, y, z=0): ..
myfunc(1, 2)
or:
args = [1,2]
kwargs = {z:3}
myfunc(*args, **kwargs)
String indexes, slices and methods are great to have:
s = 'hello'
s[2] # l
s[-2:] # lo
s[1:2] # el
s.capitalize().rstrip('o') # Hell
Triple quotes are much easier, IMHO, than vimL's varying handling of quotes:
"""Can use 'single', "double" quotes to heart's content."""
I have to run but I'm sure I could come up with a lot more...
>
> 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.
It would be good if they were better integrated, I'm not sure how
it works internally but I think an interpreter is started every time,
for example, when you use a mapping that uses one of those languages.
I tried writing a folding function once and it was too slow compared
to vimL version. It would be great if a script could be running
alongside vim, monitor contents of current line and step in when it
matches some criteria. It would be great if a script could run in
a thread and communicate back to vim.
>
>> 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 could be wrong but I think a lot of things are not done for Gvim
because they have to work in console version, too. For example a lot
of shortcuts are not possible in Gvim like ctrl-;, ctrl-", I think
because keypress processing code is shared between console and gui
Vim?
I wonder if most Vim users fall into 2 categories: those who use
gvim 95% of time and those who use console version 95% of time. If
that was the case, having less compatibility between the two
would not be a problem.
-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