Just an excerpt from a discussion going on on github:

I don't see VimR as an IDE, or to be precise, not as a full-fledged IDE: I've seen the (current) pinnacle of IDEs in JetBrains' products like IDEA or AppCode. No, they're not perfect, but they're really, really really good. I think that it is impossible—and you should not try— to be on par with such IDEs. I know that you can extend Vim(R) with plugins to a certain degree such that it becomes a kind of lightweight IDE, IDE-nano for various languages if you will. And I think that's the niche where VimR could fit in very well:

Real IDEs for serious and professional coding,

VimR as an IDE for lightweight and complementary coding and normal editing needs (personally I would love this for markdown and latex),

(Mac)Vim for pure editing needs

The following are few things I have in mind to achieve this:

First, use as many of Vim-stuff for things, like wig or auto-save on focus loss (I think that reimplementations of those features in VimR and keeping them in sync with Vim would cost too much time and effort),

However, find a good way to offer/set these features in the GUI, eg: you could add an option to ignore vimrc and offer a way of configuring VimR in the preference window for the, say, non-power user. In the background we use the Vim options to achieve those features. The power user can let VimR read their own vimrc and do whatever they want. Just a thought: whether it is a smart way of doing it is a different question,

Be a good OS X citizen, ie standard shortcuts, standard behavior whenever possible, etc.,

Integrate some IDE features, for instance a plugin system for preview pane/window for various formats, eg markdown, latex, etc.

Recently, VimR caught much more attention than I anticipated; even too much considering its premature state. For about half a day it was the number three among the trending projects on GitHub! And it has got about 350 GitHub stars already. Some people asked (me) why I do this, the point being that there already is a GUI version of Vim, namely MacVim. Or that it does not offer any advantage over the terminal version of Vim. With this post I want to clarify the rationale behind VimR.

I started to use Vim as a student and loved it since then. I wrote my theses using Vim with VIM-LaTeX! I personally think the Vim-way is one of the most efficient way for editing, if not the most efficient. However, nowadays, I most of the time use IDEs like IntelliJ IDEA or AppCode for work and for hobby projects like VimR, respectively. (I use a Vim emulator though) Therefore, I am not and won't be a real power user; rather, say, a appreciative casual user.

Modern graphical editors have many convenience features like fuzzy find (called Open Quickly in Xcode, Go to File in TextMate, etc.) or integrated file browser in the side bar. Sure, you can have all these features in Vim using various scripts like Command-T, NERDTree and what-not. However, since I don't use Vim all the time, I always forget how to use them, eg how to invoke NERDTree, even if it was me who configured the key. And, most importantly, I want to have these kind of features graphically. It's like the case of mutt/sup vs. graphical mail clients. I used to use mutt back at the university, but now, well, let me quote Roger Murtaugh from Lethal Weapon: "I'm too old for this sh*t!" :)

So, to summarize: the rationale behind VimR is to build an editor which offers the full Vim experience, even if I don't use all features of Vim, but has other convenience features—found in many other editors and in Vim scripts—in a graphical form, improving the whole editing experience. (This was @jordwalke's idea and he also encouraged me to start the project after he has seen my MacVimFramework project.)

Finally, after some days of coding, Open Quickly (or Go to File in TextMate) works in VimR. It's not perfect yet and it does not look pretty, but it works.

When the user first uses Open Quickly for an open window, VimR starts to scan and cache the content of the worspace, ie the common parent directory of the window's open buffers. The scanning may take a while if the workspace contains many files, eg the user's home folder. However once done, only folders with file system changes since then will be scanned again. (When the Vim window closes, then the cache of that workspace will be deleted.)

Some time ago, I did some code-massaging exercise and extracted a Framework part of MacVim: MacVimFramework target in qvacua/macvim on Github.

I (finally) found some time and included an absolute minimal proof-of-concept App that uses the Framework:MinimalMacVimtarget in the Xcode project. Basically it has one class (MinimalMacVim/MMAppDelegate.m) which is the delegate for everything. And for the sake of simplicity it does not handle many things like resizing the Vim-view properly when a new tab is created.

Over the course of time I'll try to improve the Framework and make it easier to use. (Eg, some delegate methods should/can be handled automatically)