Live data from Hacker News

Plans for Vim 7.4

groups.google.com

1–10 of 86 posts

Re: Plans for Vim 7.4

#4
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 , 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.

Re: Plans for Vim 7.4

#5
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!

Re: Plans for Vim 7.4

#7
post #4

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 , buffer keyword completion, a…

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

Re: Plans for Vim 7.4

#8
post #5

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

Re: Plans for Vim 7.4

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

Re: Plans for Vim 7.4

#10
post #8
post #5

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
Post reply on HN