The Grammar of Vim
rc3.org
rc3.org
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"
But wait! Tricky tasks. It's for everybody!
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.
(What reposts, you say? I was thinking of http://news.ycombinator.com/item?id=2911930 or http://news.ycombinator.com/item?id=3361993 linking to Yan Pritzkers original post, referenced in parent link. But to be fair, they are different posts, not truly reposts.)
(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).
Incorrect. Given a subjective question, the most useful comments acknowledge and consider all possible answers according to their due weight.
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 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.
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...
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.
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 ...
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.
Maybe I could try writing some plugins in the future :)
https://github.com/alloy/macvim
Screenshots:
More recently though, I just open up Sublime Text and have them work in that. My computer, my rules.
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?
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.