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