I'd say the best way to learn more about vim if you are already a heavy vim user is to join both the vim-dev and vim users mailing list in google groups. People post questions in the vim user mailing list every day and I've learned many new things just by reading the answer that other people gave.
"if you master the techniques in this book, you’ll never need another text editor. In 120 Vim recipes, you’ll quickly learn the editor’s core functionality"
If you're a heavy vim user then you probably already know the editor's core functionality.
"and tackle your trickiest editing and writing tasks"
IMO once you get past knowing the core stuff on an editor, the next frontier is scripting. If you would consider yourself advanced in vim, I would suggest starting to learn VimL
I suspect there's an opportunity/lesson lurking here somewhere.
One of the biggest complaints devs have about tools is responsiveness. The more responsive a tool is, the higher time-density of information available to a developer.
IDEs tend to suck in this regard, but Vim positively shines. Many people advocate Vim because it tends to shine in this department, even though they may not consciously realize it. Responsiveness seems to be the one vital attribute for developer tools in general. (Mosh is another example of a dev tool that capitalizes on responsiveness.)
So at first glance, it's quite odd that many IDEs suck re: responsiveness. After all, this is measurable. However, the tools to measure this on desktop apps tend to be proprietary and quite involved to use. As a result, FOSS developer tools don't do this kind of measurement, and the Tragedy of the Commons results in bloated IDEs. So the environments that avoid poor responsiveness tend to be ones that matured in a world with far fewer resources.
The takeaway: if your plans for world domination also involve a dev environment to rule them all, you'd best be measuring UI responsiveness as a part of your continuous integration/testing -- and set standards and make the devs stick by them.
I have Eclipse, Netbeans, Monodevelop, and Geany right now on 12.04. And besides having some ridiculous start up times (like, ~10 seconds, then again I have this test 12.04 partition on an old IDE hard drive from 2001. "shades" I must just be a daredevil...) they are pretty snappy, and I imagine any responsiveness shortfalls are JVM disk IO, so an old IDE drive with 60 mb sequential read / write is about as bad as it gets, and I don't lose productivity to slow software with them.
A link, or links much like this describing the "grammar" of Vim, gets reposted every few months, which is probably fine because it's a good thing to learn and share, but it would be nice if there were a HN "Hall of Fame" which would prevent reposting things like this over and over and over again. It could have either posts, or "concepts" with some of the more popular posts about Vi/Vim/etc, Emacs, C++, etc.
(However, there's also value in serendipity of new users "discovering" great links, so perhaps we can just leave well enough alone. Yeah, I know, useless comment when it takes both sides of a point).
I have been using Vim for a few years. I recently installed a trial version of ViEmu plugin for Visual Studio. With Vim inside my main IDE at work, I have the chance to really master it. But I ran into an unexpected hiccup - nobody else can use it when we're collaborating on code! Sadly, I think this might be a big enough reason to remove it.
I am increasingly disappointed in all those Vim 'emulators'. VsVim, jVi, ... They aren't vim, no plugins, no real customizations. I really like that they exist, but it could be better. We need the REAL vim in an IDE, not some vim functionality..
EDIT: I use VsVim and you can disable it with ctrl+shift+F12. This helps when working together with other people..
vim lacks a lot of modern features, and the fact that it has to be compatible with running on shells means that it can't implement a lot of things which you would need to make it look and feel like a normal editor.
For example, we'd need the ability to make windows that are only part of the screen, in order to make convenient popups (for, say, ctrl-p find in files actions). We'd need the ability to have actual graphics to separate sections. We'd need the ability to have different fonts for different buffers. Etc.
What I think we need is an IDE which is just a layer on top of vim, which gives it a few things:
* a sidebar, ala NERDTree, only good-looking and consistent with how sidebars should act, e.g. doesn't move with the other window-movement commands, can't be changed to another buffer.
* Honest-to-God normal IDE Tabs, which let you have lots of open buffers, let you see them visually and switch between them normally.
* A buit-in, fast, find-in-project/find-tag/command-t like functionality, which has nice graphics to make it easy to use and is actually fast on any project.
Etc.
And all of this can be done on top of a normal vim, making it have the ability to have all of the old plugins and configurations works. Obviously a lot won't be necessary (e.g. NERDTree), but for GUI environments, this would absolutely make vim rock.
I would like to respectfully suggest you have it backwards.
I agree a lot of that stuff would be nice with vim, don't get me wrong, but I think we don't need an IDE layered on top of vim, so much as we to do some work on DEintegrating the development environment.
I'm not advocating for getting rid of all-in-one tools, I've seen the power of VS and IntelliJ etal in competent user's hands, they are fine envrionments, if that is your preference and it makes you productive, then awesome.
What I think the programming environment world needs (not just vim) is a standard way for user interfaces to talk to tools. Right now if you come up with a great way to auto refactor code, or do inline static analysis or build tool chains or whatever, you have to target a specific environment, or redo a lot of work to have it work available in multiple tools. However if there was a standard api or protocol, the same code would work for all developers and you could focus your effort on making the tool that much better.
It isn't immediately obvious to me how this would work, and I've been thinking about it off and on for a while now, but I think it could be a major benefit to the world, in the way http/html have freed up a lot of the nonsense around programming interfaces for users in a cross-platform way. My thinking right now is being largely influenced by the git model of "plumbing" and "porcelain" command setup, where the "porcelain" is the editor/environment tool.
Anyway, I probably did a poor job of explaining my thinking, it being saturday morning and all.
> What I think the programming environment world needs (not just vim) is a standard way for user interfaces to talk to tools.
Brilliant, that way the ultimate IDE is simply your desktop.
Coming from linux, given the choice between an IDE and a bunch of shell windows running vim, gcc/g++, make, gdb, etc., I've always picked the latter. But it's missing tool communication. Now if we had some standard based on IPC that vim/gcc/g++/make/gdb/other-tools could all recognize...
This is basically all that emacs provides: glue between programs, and maybe a really thin GUI layer for interacting with them.
Which, as I'm sure many will ravenously point out, leads back to the "encapsulated environment" problem; emacs then integrates these disparate programs so tightly that I'm now locked into it.
Most of this can be done with Vim already... And the stuff that can't, like graphics, popups... I don't care for. How would you control that sidebar? With the MOUSE O.o !? I like nerdtree exactly because it's a buffer, because I can navigate it like my text. The essence of my comment above is that I want this in my IDE's, not the other way around..
Also: vim has tabs (:tabnew)... And there are search plugins for vim, fuzzy finder being one.
EDIT: But I like your idea of turning Vim into a real IDE, I've been looking into this .. Vim need to "understand" the code. Better omnicomplete, refactoring ...
I'm not blaming you specifically, but this is the problem - anytime someone points out something that could be better with vim, people jump in to show "yes vim CAN do that". And they're right. It's just that it's done worse, and takes a lot of setting up to get right.
To elaborate on the "worse" part, there are a few problems right now:
1. The plugins don't interact nicely with each other. For example, NERDTree exists, but it doesn't always play nicely with other plugins. Keeping it always stuck on the left side of the screen, taking up the same space, is not possible. If you use fuzzyfinder, for example, running fuzzyfinder from withing the NERDTree buffer will open the new buffer INSTEAD of NERDTree. This is never what I want. For another example, try jumping to a saved mark across files (e.g. 'V) from within NERDTree.
This is not even getting into plugins that will create new windows, and screw with your window layout, including messing up NERDTree.
In my vision, I would want to have a sidebar, make it keyboard-controllable of course, just make it "outside" of the actual vim, letting you control it absolutely. This is just one example.
2. The second problem is, vim looks bad. I'm sorry, but little graphical conveniences just don't exist in vim, and it is often the worse for it. For example, open Sublime Text's "find if project" drawer. It looks much better, is better convenience-wise, and it's something I use 200 times a day - I want it to be perfect. The fact that the drawer appears in the top-left, has a larger font-size, uses bold properly to make it clear what you're selecting, etc., is something that is just plain BETTER.
3. As for the current solutions to some of the things you mentioned:
Find file in project plugins: Yes they work. They don't look nice (see point 2 above), but they do exist. However, you have a choice between:
- Command-t, which is annoying to set up (don't take my word for it - look at the list of users who rant and rave about how good ctrl-p is, because it is easier to set up!).
- Ctrl-p - awesome (I use this one), but often slow. Especially when I want to display 50 results at a time (I have a large screen, I want to USE it). Coloring all the results is slow, and I'm not on a slow machine or anything. I'm not even talking about the indexing time, which luckily for me isn't a problem with my currently small projects.
- FuzzyFinder - nice, but looks terrible, and has a lot of funky behavior. E.g., the NERDTree mess (ctrl-p avoids this by writing code in the plugin to detect "common buffers" and not load things into them - not a scalable solution).
As for tabs, sure, vim has tabs - except they're not supposed to be used like the tabs everyone is familiar with, because that's what buffers are for. They're more for "workspaces". Forget the terrible naming of a feature which is similar, but different to what everyone else in the world means when they say "tab" - there are still no good ways to show which files you have open. It's not a killer feature, but a convenience a lot of people would like.
Summary: Let me get this straight. I love vim. I adore it. I kind of hate it, because having used vim, I can't find myself liking anything else - even my beloved Sublime Text 2, which is an amazing editors, frustrates me for lack of vim features.
The reason I write all of this is because I want the editing experience of vim, but the "everything-else" experience of Sublime Text 2 (or any modern editor). That would be an amazing thing.
Just to be clear: I was the person saying things could be better... But I also wanted to point out Vim CAN do most of it. I agree with you on many points...
Maybe I could try writing some plugins in the future :)
You should check out macVim. There's a build available with a real gui project tree, and it has regular GUI tabs that you want. I use it occasionally, but I like having everything in one place with tux panes:)
I use vim, but have been interested in learning emacs too. However, every time I startup the emacs tutorial, I immediately start missing the vim's semantic grammar.
Have I just not gotten far enough into emacs to discover that yet?
Not as such, though many commands can be prefixed by a "universal argument" count; "C-u 5 C-n" means "move forward 5 lines", just like "5j" does in vi.
In Emacs terminology, many vi commands can be followed by a movement command, in which case they act on the region from the current point to where the movement ends up. Instead of saying "dw" (delete forward-word), you'd use something like "C-space (mark position) M-f (forward-word) C-w (kill-region, AKA 'cut'). There are many semantic movement commands, acting on the space travelled just isn't automatic.
True but I'd say this verb-noun idiom only accounts to 15% of the user manual. For instance learning fold commands za will tell you nothing about other commands using 'a'.
Text objects are the core of editing though, stuff like z or all the g commands are more situational. I replace the contents of a string (ci"), delete a word (daw), copy the contents of an array (yi]), etc WAY more often then things like folding
