Comments on: Extensibility in Vim and Emacs

By: SirVer

SirVer — Thu, 25 Jun 2009 16:16:09 +0000

vim script is a deadend! I really enjoyed your break down. I used vim forever (> 15 years now... wow) and only took a short look to emacs, I am convinced that the two editors are the best on the planet. I agree though that vimscript is awful: limited syntax and hard to debug. I see light on the tunnel though: on the vim site, a top requested feature is the proper support for python scripting and since Bram is a Fan of Python himself (he has written his A-A-P build system in it) I consider it likely that future updates will go into this direction. I shall very much enjoy it, if this is the case.

By: Anonymoose

Anonymoose — Wed, 03 Jun 2009 20:22:12 +0000

I do not think Vim has built-in support for programmatic completion.

Vim does in fact have support for this, although it is limited (see :h complete() or :h complete-functions). However, the built-in completion for vim seems much harder to script; for instance, it seems nearly impossible to do things like adding items that would appear on the keyword-completion menu (shown via or ) onto an omnicompletion menu (shown via the unfriendly ), check whether the completion menu is visible after pressing or any of the other many keystrokes to display the slightly different versions (no, pumvisible() does not work), among other simple things like binding an item on the menu to a keystroke.

Speaking broadly: Emacs feels engineered, while Vim gives the impression of having grown piecemeal.

Although I have not used Emacs enough to have a viable opinion on it, I definitely agree with the latter assessment (despite using vim every day .

By: Mike

Mike — Fri, 01 May 2009 08:50:22 +0000

I’m an Emacs user and I’ve written one mode in for my own use (in very, very pedestrian Elisp). I use VM for email and Magit for accessing git.

Quite a few of the problems with Emacs that were mentioned have to do with its age: Elisp is the way it is partly because it originated on very limited hardware by today’s standards. The reason that displaying line numbering has appeared as late as it has is likely because of limited integration with the GUI toolkits and the requirement to work also in terminals. It’s obviously much easier to do something like that in, say, Gedit, which only has to work on Gtk.

I’m somewhat hopeful that Emacs development will pick up some speed. The project finally has a proper bug tracker and will hopefully soon switch to Bazaar for version control. The need for a shorter release cycle is also widely acknowledged, I think. Maybe they’ll even fix some of the fundamental problems in Elisp (concurrency?).

By: short and sweet elisp primer « Awhan Patnaik

short and sweet elisp primer « Awhan Patnaik — Sat, 18 Apr 2009 19:18:56 +0000

[...] on the subject of emacs this article is surely a reassuring read for those emacs users who are constantly vexed by vim users. will the [...]

By: Moonie

Moonie — Thu, 09 Apr 2009 13:15:46 +0000

I've used both Vim and Emacs a lot and can code with both editor's scripting language. My opinion is that Vim is a great text editor which can be customized easily. By customization I don't mean extensibility. It's really difficult to write good, large extensions for Vim so that they work nicely in all modes and interact well with other extensions and the rest of the system. There will never be anything like Gnus, Org-mode or CC-mode in Vim. Perhaps only cheap imitations with a small subset of features. In short, Vim is great unless you want to go beyond customizable text editor.

By: Stephen Bach

Stephen Bach — Wed, 08 Apr 2009 13:47:46 +0000

Meikel, I suspect you know more than I about how completion works in Vim, so I’m willing to concede this point. I do still think it’s unwieldy. The same function call is used to both:

Return a substring for completing — sort-of like try-completion in Emacs
Return the possible completions for that substring — all-completions in Emacs

I’ve been intending to try VimClojure. At some point I’ll put your assertion to the test.

By: mb

mb — Wed, 08 Apr 2009 06:28:25 +0000

I’m not sure, I follow your argument on completion. Vim has a wide variety
of completion functions: keyword completion, filename completion, omni
completion… You can use eg. omni completion programmatically because it
is specified by a function. Whether this function is called by Vim or by you
doesn’t really matter…

I don’t see, where this is less “heavy-duty” than emacs. But of course it depends
on the quality of the completion function. I think, eg. VimClojure’s omni completion
beats the one of SLIME.

By: Anonymous

Anonymous — Wed, 08 Apr 2009 05:11:09 +0000

(global-linum-mode 1)

By: Stephen Bach

Stephen Bach — Wed, 08 Apr 2009 03:06:42 +0000

Krylen, DZ, thanks! Anonymous, this is very informative. I wasn't aware of that irritating side-effect of ignorecase, though I have been bitten by "..

By: Anonymous

Anonymous — Wed, 08 Apr 2009 01:31:32 +0000

Another problem with vim script is its reliance on user settings. For instance, == relies on the ignorecase setting (see :help expr4). This is completely counter-intuitive, not to mention pointless; most users don't bother to check this (and rightly so, it's not the case in _any_ other language), so their scripts randomly break on certain cases (making it not portable, which is terrible for a scripting language). It's not just these operators, so many functions do this too, like search(), searchpair(), match(), etc... Also, a minor detail that has annoyed me on my scripts is that the last inserted text register (:h ".) is read-only. This makes it very hard to not break the "." command in, for instance, completion plugins. I like Vim and use it every day, but I think it would be much better of if it went with a standard (good) scripting language like Python or Lua. Vim is very extensible, it's just typically a pain to do it, and, as you said, vim script is also only applicable to Vim, whereas learning something like Lisp, Python, etc. has other applications.