Hacker News Reader

>> 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...)

only thing about Lua is that strings are immutable so certain kinds of operations can be very slow.

They are also immutable in Python.

What are you talking about?

http://docs.python.org/2/library/string.html

  >>> 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.

[1] http://docs.python.org/2/library/stdtypes.html#mutable-seque...

Oh. I guess I never thought of strings as immutable because there are so many ways to change them.

Given that they're immutable, you cannot change them. Instead all the operations returns a new, modified, string.

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.

Oh yeah, the Lua support is there, I was meaning a concentrated effort to have Lua replace VimScript completely.

99% of vim scripts still use VimScript.

I think this happens for a few reasons:

  - 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?

  | although more recently some distributions

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.

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.

[1] http://gitorious.org/evil/pages/Home

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'm thinking of making the switch. Are you able to port your vim plugins to emacs in evil mode?

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.

[1] - http://www.emacswiki.org/emacs/Evil

[2] - http://www.emacswiki.org

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...

You can write plugins with Racket. However the API is AFAIK the same as for Python or Ruby so you can't really escape vimscript.

Want lisp the original source for Bill Joy's vi supports it.

http://ex-vi.sourceforge.net/

Happy hacking =)

The vim voting page describes the IDE features as a built in debugger and shell window.

A vimL API for parsing code, with AST, code transformations, and un-parsing would be a huge step in that direction.

This would allow plugins to all sorts of crazy stuff, with less magic, less regex, and more robustness.

This would make code completion better, too.

Background tasks, check out dispatch.vim[1]

https://github.com/tpope/dispatch-vim

Thanks for pointing this out! But I think you meant https://github.com/tpope/vim-dispatch.

Sorry my bad. Typing from memory on my phone.

Thanks for clearing it up!

If you code C#, OmniSharp is quite awesome:

https://github.com/nosami/Omnisharp

Real intellisense, find usage, refactor, etc.

In terms of "pointing out stupid mistakes to you before you try to compile/run your code", which is a very important IDE feature in terms of not wasting your time, you can go pretty far with syntastic[1]. This does not help with verbose languages which need autocompletion (you know the ones I'm talking about), managing import lists or automated refactoring, but it's still really good to have.

1: https://github.com/scrooloose/syntastic

Why is everyone talking about "add IDE features", it doesn't sound like he is planning to implement that request. He was just listing out the top requests.