C++ vim IDE. Things you'd need from it

Question

I was going to create the C++ IDE Vim extendable plugin. It is not a problem to make one which will satisfy my own needs.

This plugin was going to work with workspaces, projects and its dependencies.
This is for unix like system with gcc as c++ compiler.

So my question is what is the most important things you'd need from an IDE? Please take in account that this is Vim, where almost all, almost, is possible.

Several questions:
How often do you manage different workspaces with projects inside them and their relationships between them? What is the most annoying things in this process.
Is is necessary to recreate "project" from the Makefile?
Thanks.

Reason to create this plugin:

With a bunch of plugins and self written ones we can simulate most of things. It is ok when we work on a one big "infinitive" project.
Good when we already have a makefile or jam file. Bad when we have to create our owns, mostly by copy and paste existing.
All ctags and cscope related things have to know about list of a real project files. And we create such ones. This <project#get_list_of_files()> and many similar could be a good project api function to cooperate with an existing and the future plugins. Cooperation with an existing makefiles can help to find out the list of the real project files and the executable name. With plugin system inside the plugin there can be different project templates.

Above are some reasons why I will start the job. I'd like to hear your one.

Solution 1

• debugger
• source code navigation tools (now I am using http://www.vim.org/scripts/script.php?script_id=1638 plugin and ctags)
• compile lib/project/one source file from ide
• navigation by files in project
• work with source control system
• easy acces to file changes history
• rename file/variable/method functions
• easy access to c++ help
• easy change project settings (Makefiles, jam, etc)
• fast autocomplette for paths/variables/methods/parameters
• smart identation for new scopes (also it will be good thing if developer will have posibility to setup identation rules)
• highlighting incorrect by code convenstion identation (tabs instead spaces, spaces after ";", spaces near "(" or ")", etc)
• reformating selected block by convenstion

Solution 2

There are multiple problems. Most of them are already solved by independent and generic plugins.

Regarding the definition of what is a project.

Given a set of files in a same directory, each file can be the unique file of a project -- I always have a tests/ directory where I host pet projects, or where I test the behaviour of the compiler. On the opposite, the files from a set of directories can be part of a same and very big project.

In the end, what really defines a project is a (leaf) "makefile" -- And why restrict ourselves to makefiles, what about scons, autotools, ant, (b)jam, aap? And BTW, Sun-Makefiles or GNU-Makefiles ?

Moreover, I don't see any point in having vim know the exact files in the current project. And even so, the well known project.vim plugin already does the job. Personally I use a local_vimrc plugin (I'm maintaining one, and I've seen two others on SF). With this plugin, I just have to drop a _vimrc_local.vim file in a directory, and what is defined in it (:mappings, :functions, variables, :commands, :settings, ...) will apply to each file under the directory -- I work on a big project having a dozen of subcomponents, each component live in its own directory, has its own makefile (not even named Makefile, nor with a name of the directory)

Regarding C++ code understanding

Every time we want to do something complex (refactorings like rename-function, rename-variable, generate-switch-from-current-variable-which-is-an-enum, ...), we need vim to have an understanding of C++. Most of the existing plugins rely on ctags. Unfortunately, ctags comprehension of C++ is quite limited -- I have already written a few advanced things, but I'm often stopped by the poor information provided by ctags. cscope is no better. Eventually, I think we will have to integrate an advanced tool like elsa/pork/ionk/deshydrata/....

NB: That's where, now, I concentrate most of my efforts.

Regarding Doxygen

I don't known how difficult it is to jump to the doxygen definition associated to a current token. The first difficulty is to understand what the cursor is on (I guess omnicppcomplete has already done a lot of work in this direction). The second difficulty will be to understand how doxygen generate the page name for each symbol from the code.

Opening vim at the right line of code from a doxygen page should be simple with a greasemonkey plugin.

Regarding the debugger

There is the pyclewn project for those that run vim under linux, and with gdb as debugger. Unfortunately, it does not support other debuggers like dbx.

Responses to other requirements:

• When I run or debug my compiled program, I'd like the option of having a dialog pop up which asks me for the command line parameters. It should remember the last 20 or so parameters I used for the project. I do not want to have to edit the project properties for this.

My BuildToolsWrapper plugin has a g:BTW_run_parameters option (easily overridden with project/local_vimrc solutions). Adding a mapping to ask the arguments to use is really simple. (see :h inputdialog())

• work with source control system

There already exist several plugins addressing this issue. This has nothing to do with C++, and it must not be addressed by a C++ suite.