

Plans for Vim 7.4 - davekt
https://groups.google.com/forum/#!msg/vim_announce/ZWWgK9aXQ2Y/IMObY8lBFm0J

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

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

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

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

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

~~~
siddboots
#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?

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

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

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

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

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

------
coldpie
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!

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

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

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

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

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

Works great!

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

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

------
coolwanglu
Hmm, the signature looks interesting.

~~~
GhotiFish

      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

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

~~~
munchor
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_

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

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

~~~
keypusher
A paying vim customer?

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

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

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

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

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

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

A JavaScript debugger integration would be awesome too.

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

------
SandB0x
Would love a package management solution.

~~~
darklajid
Vundle is what I use.

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

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

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

Sure feels like 2013.

