Plans for Vim 7.4 | Hacker News Reader

Plans for Vim 7.4

groups.google.com

205 pointsdavekt83 comments

I am curious what "add IDE features" means. It seems like a wide-open feature request.

A few things I can think of:

* Better support for background tasks .. :mak, :grep, system(), :! without interrupting editing.

* Fancier errorlist and locationlists. cexpr()/lexpr() really make you fit round pegs into square holes.

* Better omni-completion performance (any completion dialogs other than <C-N>, buffer keyword completion, are unusably slow for my purposes).

* Built-in support for some filesystem operations. NERD_tree/:! can be clunky, and dropping into the shell isn't always ideal.

* Real shell buffer .. I know I'll get my head cut off for this because it is quite emacs-y, but it would be nice to be able to run my shell in a buffer. At the very least, it would be nice to have :sh be a somewhat capable terminal that could handle colors and generally feel like a normal terminal.

I'm excited to see 7.4 because it looks like some real new direction for the project, for better or worse. 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.

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.

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

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.

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.

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

With the development beeing rather slow as it is, wouldn't Vim benefit more from improving the whole community aspect as well as connectivity?

I still use Vim, but it is a bit annoying to see well done solutions I've been using for years fall behind new projects (Hello Firebug) that accomplish more in a year than others in 20 years.

If Sublime Text was Open Source and the vi mode better I'd switch in an instant. And probably a lot of people too.

I don't want to sound snobbish and arguing without helping isn't the way to go in the open source community, but man, all that stuff that has been in development for so long, thought of in dusty university rooms, presented in worn 70's summer dresses...

It reminds me of the old tailor couple around the corner. They wont go away and probably have a lot of years to life left. A handful of people still value their skill and love to pay more. But it's an old house that hasn't been painted for a long time. You will only find it in the yellow pages and even then you're having trouble to actually find the shop because it's tiny and the house looks like it's soon to be demolished. The machines they use are old and they are the only ones who actually know how to fix them. If they die the shop is gone for good.

The same goes trough my head when I look at Vim's homepage, or Molenaars. They look like someone died or moved on to a life without the internet.

They don't make the impression that anything of value can be found. But in some places there is, scrambled across different pages by different people of different generations. Modern technology hammered into old shells. A reminder here that scripts can also be found on git. A wiki hosted on wikia there. GUI builds for Mac here, Windows there, none using any new features of the OS. It still runs, but there isn't really any love put into it.

If people talk about Vim plugins I only hear how bad VimScript is. If I install one I get it on github, not the script repository because that's where the skeletons lie. The installer I use (and the only one up-to-date) is made by the cream developers. No clue what I'd even do if they stopped producing them.

Vim became the double-edge razor a long time ago. It's cheap, it just works and I can pass it down to my kids. All it needs is some learning. But it's only noteworthy because every other kind of razor produced today sucks in one way or another.

The Vim project seems to favor making everything work themselves.. Which is a shame, so much would be gained from learning from other projects and keeping up to date with best practices elsewhere.

My own very brief discussion about encryption in Vim makes me conclude that Bram doesn't want to learn from others (not from me, from current best practices in crypto) and doesn't keep in touch with others.

> If Sublime Text was Open Source and the vi mode better I'd switch in an instant. And probably a lot of people too.

You might but the thing is, Vim has been around for over 20 years and hasn't really lost any steam (and vi for another 20 years on top of that). Sublime has only been around for 5 years and it's closed-source meaning if the development dried up or something, it's a dead project. Vim has a high bus factor since it's only developer is Bram, but at least it's open-source so it can be taken over by someone.

I would say all the aspects that you find lacking with the way Vim is developed, in my opinion, is what makes it the stable, powerful editor it is today.

It is somewhat following the linux model (with Linus as the primary developer in the early days).

Just like linux, I believe this has added to the widespread popularity of Vim (ie. it is available by default on most distributions).

Vim doesn't need to "modernize". I would say its availability and ability to still stay relevant is more modern than most other open-source software.

emacs is open-source and has a really good vi mode (evil). have at it.

I'm not sure about IDE features. The whole reason I use vim in the first place is precisely because it's not an IDE. I don't want integration, I want unix instead. It's the same reason I use dwm for my desktop setup and configure everything by hand as opposed to using a desktop environment. I want technically simple software. Right now I could already easily configure/integrate vim to use gdb, gcc, git, jshint, etc. using vimscript. I prefer that over hardcoded integration. I'm just curious what's meant by IDE features. Maybe I'm misinterpreting it. At the end of the day, I trust Bram. He's created an amazing text editor and maintained it for more than 20 years.

Well, either way the "Better IDE Features" won't be making it into Vim 7.4 (as Bram hinted at), so you don't have to worry just yet. As for the specifics of the IDE features, they've been summarized here: https://news.ycombinator.com/item?id=5680216

Well, one of the reason of VIM success is its configurability.

I'm guessing the "IDE" features could be enabled/disabled as will, just as you have the option of using vim as just "vi".

I sort of want the inverse of IDE features; I want VIM to support APIs to make it embeddable. I should be able to use VIM as a window _inside_ eclipse, visual studio, XCode, etc. VIM will simply never replicate the thousands of man-years of work that has gone into the IDEs. And if it did, all it would achieve is being an IDE just like they are already. But I think with a relatively small amount of effort it could publish a binary API spec that would let any IDE embed it's windows (like how Eclipse embeds Internet Explorer windows).

Still motivated and eager to make improvements (and not really trivial ones) to his (free!) software after so many years to the benefit of the whole software community.

Kudos to Bram Moolenaar.

Version numbers are infuriating. Dates don't overflow, people! If you're doing incremental development that doesn't have a concept of a "stable release", just use dates. This applies to projects like Firefox and the Linux kernel. I was pretty annoyed when Linus went with 3.x. Eventually, it's going to run into the same problem 2.6.x did. Date-based versioning would have lasted forever!

For internal purposes, you're probably right. For distribution and documentation purposes, I think it's much easier to understand "this plugin works on 7.3 or later" than "this plugin works on 2010-08-25 or later."

I think it doesn't have to include fully qualified date. For example, Ubuntu uses date-based versioning, e.g. 13.04

Thanks for pointing that out. It never occurred to me that their versioning is date-based.

You are assuming a monotonically increasing version number. What happens when you need to go back to the old "version" and push out an update? For instance, you shipped 3.0 a few months back but most of your users are still on 2.7. Uh, there's a bug on 2.7, you need to push out a fix. If you are doing versions by date, then there is no easy way to distinguish parallel development.

Just to play devils advocate, you could use both versioning schemes. For example, 13.01.24 could indicate it was the 24th revision of the 13.01 release (as opposed to being released on the 24th of the month).

I like this idea the best, but I think revision numbers are conventionally prefixed with a dash;

    13.01-24

http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pac...

(i can never quite distinguish between revisions and releases... when is each used?)

Yeah, that would be better.

In this context a revision is just a bug fix release, the same as a "point release" or "minor release" or "patch version." I'm sure there are terms I'm forgetting. A micro-version increment, where the system is ${major}.${minor}.${micro} (in what the kids call "semantic versioning," but what used to just be called "not versioning like an idiot.")

Yeah, that wouldn't be the slightest bit confusing.

Version numbers for applications with a public API should have meaning:

http://semver.org/

The number one thing I'd want in vim is support for Multi Cursors, ala Sublime Text. This is something that's very hard to get right with a vim plugin, but could probably be added to core vim much more easily.

Vim Align and Ctrl+V Shift-I works for me but I agree... multicursors would be awesome.

I've been using this for a few weeks: https://github.com/terryma/vim-multiple-cursors

Works great!

Actually, I found this plugin to be kind of buggy. However, I'm sure it'll get better soon, as it only had its first release a few weeks ago.

Things that I really appreciate in the list:

* add IDE features (debugger integration, shell window)

* add integration with Python instead of inventing more Vim script

* add encryption for the swapfile

And something that could be included in that list:

* Built-in support for multiple cursors

Hmm, the signature looks interesting.

  E  M  A  C  S
  s  e  l  o  h
  c  t  t  n  i
  a  a     t  f
  p        r  t
  e        o
           l

ha ha, love it.

Come on , there is room for both VIM and Emacs , but i must say VIM seems more popular today.

Maybe on r/vim, but on r/emacs it seems that Emacs is, by far, the most used text editor in the whole world!

What I mean is that it's hard to know which editor is the most popular, it really depends on the communities you visit

Just because people who follow the vim google group want more ide features and python integration doesn't mean thats what most vim users want. Why don't they fix the obvious flaw, mouse integration? (I know, because it would be hard)

Mouse integration into a console vim window? It may be obvious to you but it's literally never affected me, I haven't even run GPM in like 10 years.

New features are voted on not by mailing list/Google group participants but by users who have donated at least €10 to the Ugandan charity that Bram sponsors via Vim development.

Also, I'm not sure in what sense mouse integration is "the obvious flaw", given that (A) it already exists if you use the GUI version, or in the terminal if your terminal supports mouse reporting (see :help mouse-using) and (B) most Vim users tend to actively avoid the mouse anyway.

Wait, what? Since when does being in the google group let you vote? I thought you had to be a paying customer/sponsor to vote.

A paying vim customer?

yes you need to donate 10 euro to the ugandan charity Bram chose to support.

http://www.vim.org/sponsor/

Because many, many vim users (majority even?) are running vim on a headless *nix server with no display or display software, let alone a mouse. Anyway, there is already "set mouse=a", or use something like MacVim or another port of vim to graphical UI.

Maybe because mouse integration already works?

vi with mouse integration? They have had this for years. Download the source and grok my friend. You probably are running nvi and not vim. Also in either your terminal or x you can simply middle click your mouse if you need to mouse copy/paste. I recommend addressing in ex mode or using the vi visual mode commands to do it. If your really dependent on "drag/drop" gui style editing using ex proper will defeat that. In vim I'm sure a simple script would even bring it to the gui drag/drop concept to the editor by automating addressing from mouse selection. Though it would be slower for the end user and simply not provide the flow and control ed and vi/ex users have had for years.

1. Expand the vim philosophy to be a whole OS UI experience, be able to control all apps on the screen using vim controls.

2. jokes aside, the most important need is probably better repl: eval result should pop up on screen.

Not quite sure what you mean - have you tried ScreenSend?

I've been using Vim for close to 10 years. Can't live without it. My only gripe is the session file created with mksession is quite huge in size.

I would love to see JavaScript integration so we can script vim with JavaScript.

A JavaScript debugger integration would be awesome too.

A properly integrated and efficient ido for vim would be nice. CtrlP didn't work as well the last time I tried.

Would love a package management solution.

I'm sure you've heard of pathogen, but if not, check it out here: https://github.com/tpope/vim-pathogen. I've been using it for a while and it's fantastic.

Vundle is what I use.

I use Vundle too but it's often frustating. The package management in Sublime Text looks much slicker, but then Sublime Text is slick overall.

Pathogen—as mentioned—is great, but I've switched to Vundle and find it easier to manage.

Vundle (https://github.com/gmarik/vundle) is good enough for me.

Since it hasn't been mentioned yet, I'll add https://github.com/MarcWeber/vim-addon-manager

(Not to be confused with http://packages.debian.org/sid/vim-addon-manager -- and yes, the author of the former got permission from the author of the latter to re-use the name.)

Anyone know how long it would take for the 7.4 update to reach MacVim?

"Besides that, if you are maintaining runtime files, please send me any pending updates."

Sure feels like 2013.

Reply on news.ycombinator.com