On Jul 29, 7:23 pm, AK <
andrei....@gmail.com> wrote:
> On 07/29/2011 02:51 PM, Ben Fritz wrote:
>
>
> > 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.
>
Ok, so now you need to learn two languages, one which looks just like
VimL but apparently won't be usable in scripts, and python. Why not
just use VimL? My point that learning how to use Vim automatically
teaches you basic Vim scripting stands regardless of whether you can
use VimL commands in python or not.
> 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.
>
I could see this getting annoying, but in practice I haven't had a
problem. Most authors prefix with the plugin name any variables,
functions, and the like which are part of an external API, or they use
<Plug>. Internal variables and functions mostly use s: to make them
private to the script.
Yes, it's a neat feature missing from vimscript, but it's hardly
crippling. People have been coding in C for decades without using
namespaces.
> 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..
>
how about:
let {a:var} = {a:value}
:help curly-braces-names for details.
Again, this is completely missing from many languages in common use.
And actually for this purpose, i find Vim easier to read.
> 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)
>
Sorry, I don't know python, so I'm not sure what this does. It looks
like you're demonstrating 2 things:
1. In Python, you can define functions in a way that you do not need
to call them with all the arguments defined. Vim can also do this.
Admittedly, Vim does not provide a built-in way to provide defaults
for those arguments, but it is not hard to check for their absence and
default some internal variable to some value.
2. I'm really fuzzy on this one (the syntax is very cryptic IMO, and I
don't know python at all), but in python, perhaps you can pass in
arguments as part of a list instead of passing them in as defined in
the function prototype. While an interesting feature, I fail to see
the utility. It looks like a good way to obfuscate code to me.
> String indexes, slices and methods are great to have:
>
> s = 'hello'
> s[2] # l
> s[-2:] # lo
> s[1:2] # el
Agree, these would be nice to have. There's strpart() but it can be
awkward to use.
> s.capitalize().rstrip('o') # Hell
>
I don't see very many advantages of having methods as part of strings,
over having functions which act on strings.
> Triple quotes are much easier, IMHO, than vimL's varying handling of quotes:
>
> """Can use 'single', "double" quotes to heart's content."""
>
That looks like a neat feature. It certainly is nicer than the
escaping mechanisms required by almost every other language, including
VimL.
>
> 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.
>
>
I thought it could...am I wrong? I have a vague idea this is how some
of the "background command" and interactive shell plugins work, but
maybe I'm mistaken. I haven't looked into any of these. Like I said,
though, better integration with the interpreters would probably be a
plus.
I'm surprised to hear you found python slower than Vim for something.
One of the big reasons given for writing in a different scripting
language is speed improvements. Maybe there's just a big tradeoff if
you call the interpreter for small tasks many times instead of one big
task a few times.
>
> >> 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?
>
Keypress processing code is shared to some extent, but that's not why
gvim cannot process codes. A lot of it has to do with the internal
encoding of those keycodes, if I understand correctly (it all sounds
very complicated to me). There have been multiple proposals (some very
recently) for updating Vim so that both console AND gvim can use most
key combinations in mappings. But, nobody has stepped up and written a
patch. So far, it's been a request only.
> 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.
>
That may be the case, but a big plus of Vim is that it acts (almost)
the same no matter where you run it. Putting that in jeopardy by
splitting it into two separate apps seems silly at best. People can
and do build a Vim without GUI enabled if it really matters to them,
so I don't think you'd buy much except for new places to introduce
differences in behavior between console and gvim.
--
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
