>> I'm sad to see VimScript de-emphasized, having invested a good bit of time in getting good with it, but VimScript is pretty slow, so this is good news.
I'm a Vim enthusiast who hasn't tried Emacs, but one thing I've heard that makes me jealous is that they can script their editor using a flavor of Lisp. This is extra awesome for devs whose primary language is already Lisp.
Sometimes I wish for a Vim-like editor with a nicer scripting language, but "Vim-like" is such a huge target at this point that any effort is bound to displease most users by omitting the one tiny feature they personally love.
If Python becomes useful for scripting Vim, that would be awesome in my book.
Ive always thought Lua would be a good vim scripting language.
* It's designed to be embedded
* It's easy to expose functionality and API's
* It's fast
* IME if other languages are also embedded, and a thoughtful API/plugin arch is created, functionality from other language plugins can be easily accessed in lua. (I know, bunch of caveats there, but if I'm dreaming...)
Vim supports scripting with Lua similar to the support it already has for Python, Perl, Ruby, Racket. Your instance of Vim just has to be compiled with that option. See ':h lua'. One major problem with its support for scripting languages has been that you can't count on other users having a Vim compiled with proper support. This includes Python, although more recently some distributions (e.g., I think, Ubuntu) have had standard Vims where Python support was by default compiled in. Apparently improvements to Python interface in 7.4 will go beyond those currently offered for outside languages, which many find somewhat clunky.
- First, as you pointed out, not every user is guaranteed
to have your favorite language installed. But they will
have VimScript whenever they use vim.
- Second, even if a user has your favorite language
installed, the version of vim they have might not be
compiled with bindings for that language. Only VimScript
is guarateed to be compiled in.
- Third, VimScript is the only language in vim that's not
crippled in some way in respect to functionality. All
the other languages it supports have to rely on
VimScript itself in order to perform some vim-related
functions. In some languages, this makes it so that you
might as well be using VimScript to begin with.
#2 has been the biggest drawback in my experience. It often isn't realistic to compile your editor from scratch, particularly when you are working in a windows environment without administrator rights to your machine. This means that any extensions (e.g. dbext) dependent on those bindings are unavailable.
Is there a reason why there is no portable binary compiled with bindings for perl, python, lua, et cetera?
Even CentOS 4 had a Vim with python in it. The issue that I always came up against was Ruby support. Ruby wasn't compiled in, and some Vim plugins (e.g. LustyExplorer, FuzzyFinder) relied on it. I worry less about that now that Ctrl-P (written in Vimscript) has replaced those for me.
>>> a = "string"
>>> a[1] = 'g'
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'str' object does not support item assignment
>>> b = a.replace('t', 'g')
>>> b
'sgring'
>>> a
'string'
>>> id(b)
3065252256L
>>> id(a)
3075481632L
Also from here[1]:
Strings and tuples are immutable sequence types: such
objects cannot be modified once created.
evil-mode[1] is a really well crafted vim emulator for emacs. Not those clunky emulations that barely do hjkl but something that replicates even text objects or repeat (.) .
This made my migration from vim to emacs possible.
After over 20 years of very happily using vim and other vi-clones, I'm in the process of making emacs+evil my main editor.
Making the switch is slow and painful for this veteran vim user who has perfected his vim environment, but I can already see that the emacs environment that I build will be superior... eventually.
Plus, I get the joy of scripting my editor in elisp and eventually guile (I hope). No more vimscript for me!
That said, vim is a wonderful editor. Even if vim ultimately isn't as flexible as emacs, it's still incredibly powerful; and there's a lot of cross-fertilization going on between the two editors, with vim users getting inspired by emacs features and packages and writing vim equivalents and vice-versa.
I don't know if it's possible to automatically port vim plugins to evil. However, according to the emacswiki page on evil[1], a number of vim plugins have been ported:
evil-surround: Port of Vim’s surround script.
evil-numbers: Vim-like increment and decrement.
evil-leader: Port of Vim’s mapleader.
evil-rails: Port of rails.vim.
evil-nerd-commenter: Port of Vim’s Nerd-Commenter
Also, there are many emacs packages that provide functionality that's more or less equivalent to various vim plugins (sometimes even unenhanced emacs will already be capable of doing what you need).
Just a couple of tips for vim fans giving emacs+evil a go:
* Don't expect to quickly master emacs or quickly be able
to replicate the vim environment you spent years
perfecting. Getting emacs set up nicely will take a lot
of learning, tweaking and hacking (especially if you
want to make it more vim-like). Be prepared for that.
* Come to #emacs and #evil-mode on freenode for help.
* You might want to go through the emacs tutorial (C-h t)
before you install evil or do any other customizations.
That'll teach you some basics of emacs that you'll run
in to elsewhere, and help minimize confusion.
* Search the emacswiki[2] on any topics you're interested
in. There's a lot of good stuff there.
I use both regularly, but considering the investments involved I would say that I "switched to emacs" and vim is simply there when I need it.
I agree with your tips but the one thing I would add is that if you're worried about porting your vim plugins, don't. I use evil and the evil-plugins you listed happily, but beyond those awaits a vast world of emacs plugins from hordes of emacs.d hoarders, ready to eval your kinkiest, textiest dreams.
Basically, don't get hung up on plugins. They exist because they don't make up the core of your editor, and if you find yourself liking emacs even a little bit then it is very likely you'll find a suitable replacement for each of those functions.
agreed. It's a phenomenally "true" interpretation of Vim. Focusing on the "operator", "motion" and "text object" abstractions and making them composable functions is just sweet. Honestly, I think it's a better approach than how Vim does it...
I'm a Vim enthusiast who hasn't tried Emacs, but one thing I've heard that makes me jealous is that they can script their editor using a flavor of Lisp. This is extra awesome for devs whose primary language is already Lisp.
Sometimes I wish for a Vim-like editor with a nicer scripting language, but "Vim-like" is such a huge target at this point that any effort is bound to displease most users by omitting the one tiny feature they personally love.
If Python becomes useful for scripting Vim, that would be awesome in my book.