Welcome back, good sir. The basic features of a modern IDE are syntax highlighting that is bullet-proof, and smart code-completion/symbol-completion that knows what keywords or symbols are valid in a given context.

Most of all, it shouldn't get in your way while you type code. Some IDE's go too far and they slow down productive programmers by making them stumble over automatic insertions.

Some kind of build system is also desirable so that a user can easily compile/link potentially several outputs from an entire "project" is very useful. You should at least support invoking an external command such as make or cmake to do this part, but having built-in support to do it might offer a better user experience at the expense of portability. Figuring out how to use Make or CMake or other command-driven tools and still give the IDE user a first-class user experience is the ultimate wet dream.

Another very useful feature is smart jumping to declarations, definitions, or references for symbols. Being able to easily find where a particular symbol is referenced as opposed to an unrelated symbol of the same name is extremely useful when refactoring or exploring a code-base.

Having either an addon/extension API or a very extensible UI is very useful for those of us that want to overhaul the UI for something like a Vim-like modal interface. Supporting Vim and Emacs modes well out of the box would be a very strong selling point.

Compiling and marking warnings/errors while you type is lovely to have, but I'm not sure C is efficient enough to parse on-the-fly. It's not necessary, but it should be added to the wishlist. If it can be accomplished it can potentially improve productivity. Support for static analysis or linting either on the fly or on event is also extremely useful.

This is all very theoretical. I don't think you realize the amount of work that would go into building one of these. Even if you started with an open source kit like Code::Blocks and just customized it for C programmers it would still probably be months or more of work. Building one from scratch could take years.

C is a very portable system language so it still has a very strong place in this world. But the language has a lot of downfalls. Don't expect to make C "hip" again. Your target audience will be rather old for the most part, or rather elite in terms of job description. Most of them are probably hacking on free software platforms, and they'd probably want an open source, portable, development environment too.

Personally, I'd really enjoy a rich development environment that is text terminal/command-based, but that might limit the environment in some ways that ultimately hurt accessibility/productivity (but ultimately aid performance).

Make no mistake, this is a Monday project.

Can you make it so F12 does a compile, cheers.

Longtime Allegro users will probably remember RHIDE back when Allegro was pretty much a DJGPP/DOS thing. I've thought that modern IDE's could learn a lot from RHIDE because it felt so lightweight.

Thanks, everybody, for the suggestions. One other thing I'd throw into the ring is to disable clipboard usage. NO copy and paste, write your own code in reusable functions.

Don't worry. I love Mondays.

I've used a static code analyzer that did something along those lines (detected large amounts of re-used code) called SonarQube.

CB isn't too bad, but the Code Completion extension needs to be rewritten. One of the key problems is that it doesn't seem to understand file context. If a symbol is declared as file-level static in file foo.c, CB will add it to the list of code completion symbols in bar.c. For functions, this is a big deal, because small 'helper' leaf functions that exist only in one file should stay encapsulated in that file.

One nice feature of QT Creator is that if you press '.' when accessing a member of pointer to a struct, it will automatically replace it with '->' thereby avoiding an obvious compile-time error.

Most C++ IDE's will automatically default to creating a file with the cpp extension, leaving you to rename the file to foo.c at creation, or, most egregiously, after the file has been created. If the later is done, it fires off the symbol scanner in the IDE again, and unnecessarily, because none of the symbols have really changed, but the IDE needs to know what symbols exist in what file.

In C++, structs are really classes with public members by default. In C, classes don't exist, and structs are really for data unless you use a lot of function pointers, in which case you should be writing in C++. Code completion in many C++ IDE's wants to treat structs as classes, which can lead to subtle bugs if you let the IDE have its way.

One slight difference between structs and classes: in C, I prefer to not to typedef my structs. Classes in C++ (and therefore structs) don't require typedefs. If an IDE is going to recommend a struct symbol, it had better add the word 'struct' to the front, unless it has been declared with a typedef.

These are just off the top of my head. I don't hate Visual Studio, or Code::Blocks, or Vim. I actually love neovim, for what it is, it's great. They're all usable tools, but they all have flaws.

>

YES. Thank you. I HATE that.

So, most IDE's are made for programmers, by programmers. All of these are fairly obvious issues that most of the users [programmers] would like to see fixed. IDE's are written by the people [programmers] who know how to fix them.

But the list of issues could go on. Weird bracketing, for instance, is common to all the code completion extensions I've ever used.

The search for the ever elusive perfect IDE continues... Unless I ever get around to making one. But Bams is right. This is not a small project.

Multi-compiler integration, for cross-platform use.
It should work with gcc, g++, and MinGW versions thereof, plus MinGw, Cygwin, and similar on WIndows (plus MinGW on Linux) and gcc on OSX.

Easy to set and comprehend compiler flags.

Some form of makefile integration.

A source-aware debugger is critical.

The actual text editor, I'd like to be as lightweight as possible. (I'd suggest looking at Scintilla, which is what I use for almost everything.)

Declaration lookups. It's nice to be able to highlight an identifier, and determine where it originates, across files.

That depends on the size of the codebase. I wouldn't mind having a setting to toggle that at times. I haven't seen anything that can read symbols in includes, and actually use them in that file without using a full global symbols map.

Toggling the global symbols map on a per-file basis, or mapping included symbols in scope with files that have those includes, would be a nice touch.

I honestly detest most IDEs as raw code editors, because they often become too bulky--and slow!!--to be useful and efficient.