Really. I'm not kidding. It's all there. Not for everybody but /clearly/ very much for you. (Unless you move the incredibly complex goalpost you've set up here).
It has a learning curve to configure and to use but if the above 28 is what you want as you say you /can/ have them all.
All of them. For real. Working. It's on you now.
29. vim or emacs keybindings if you want that.
If so i'd be impressed - and TBH ~17 years ago i did use Eclipse CDE and found it superior for C and even C++ code compared to what i saw people praise MSVC for (though MSVC's debugger was better than the GDB front-end functionality Eclipse CDE provided), so i don't think it is unlikely. I do remember it having some neat integration with Trac back then too. I mainly stopped using it because the computer i had at the time struggled to run both Eclipse and Mozilla at the same time :-P. But ~17 years ago i always praised it with the only annoyance (resource usage aside) being that weird "workspace" approach, but that was minor.
I didn't think much about it because it seemed to have fallen out of fashion since then so i thought it is just limping along.
I think i'll be trying it out then :-) perhaps it is time to go back to Eclipse CDT if that is the case.
EDIT: eh, tried it, not impressed. First of all Eclipse crashes or hangs almost every time i try to edit the settings.
Then i tried to make a test library, "librola" (random name) to be used by a program "rolathing". First i made the library using the managed C project with the "Linux GCC" toolchain that was already available. Typed some methods "int rola_init" (dummy, sets some static initialized variable to 1), "int rola_gimme" (returns 42) and "void rola_shutdown" (sets the initialized variable to 0).
1. I forgot to mention it in the above but Lazarus and other IDEs already have this anyway and it seems Eclipse CDT also has it, except it doesn't work: i tried to have the IDE generate the bodies for these functions in a C file (that didn't exist yet) using the "Implement methods" command that seemed the most appropriate (and i couldn't find anything else anyway) but that didn't work. I thought it was because there wasn't a C file so i made an empty one with the same name as the header file but again it didn't work - even after adding an #include in the C file for the header file it didn't seem to match the two. So i typed these by hand even though i believe it should either use the C file with the same name as the H file (a common use) or at least ask me.
2. I made a C program with managed C project and added a new "main.c" file to it. I typed "rol" and pressed ctrl+space to see any suggestions and there were none, so it basically failed #2 and #28 above. I typed the code manually, used printf to print out the return value of "rola_gimme" and even after saving there were no errors or warnings at all even though the C file had no include files at all.
3. Tried to compile and as expected, it failed. There were no quick-fixes or anything else i could do from inside the IDE - there was an "info" message that i should include stdio.h to get the printf definition but the IDE wouldn't help there by adding it itself, i had to manually type the code. And TBH most likely that message came from the compiler and the IDE was oblivious to it anyway. Obviously no message about which file to include to get the rola_init, rola_gimme and rola_shutdown definitions, let alone doing those for me.
I lost interest at that point because it not only was unstable but also failed at the first thing i tried that would show the IDE really understood the source code. Note that this whole "automatically add header files" isn't even something i came up with, i remember a trial version of C++ Builder i tried years ago to do that and while i didn't check to see if it only does it for the header files that come with it or also for your own libraries, the latter would be an obvious thing to do anyway as the library was already part of the workspace and thus known to the IDE - and Eclipse didn't do either anyway.
But just in case, i tried to at least try the debugger so i thought to add the reference manually - which i did but Eclipse crashed every time i pressed the "Apply and close" button. However restarting it seemed to have the setting applied anyway so i could at least try the debugger. And at the end i couldn't figure out how to convince Eclipse to use the shared library project next to the program project, no matter what i tried (i'm sure there is a way but IMO all i should have to do is, as i wrote in #26, check the library's name in a listbox with all the available libraries - and FWIW there was such a thing but it did absolutely nothing, Eclipse only started realizing there is a library somewhere when i started adding in paths, etc, manually but i failed to make it build).
So at least i wrote a "int foo() { return 42; }" (in more than one line :-P) in main.c and then have an endless loop in "main" and run the program under the debugger. The program wrote a bunch of "42"s in the stdout so i put a breakpoint in "return 42;" and modified it to "return 48;" - then continued and... nothing happened, it kept outputing "42". I tried to rebuild the "current source file" and even "rebuild all" but it didn't change, i had to restart the program, thus failing (as far as i can tell) #11.
On a semi-positive side i made a "int lala(int x, int y) { return x*y; }" and the debugger was able to run this function, but then when i tried it with something a little more practical like implementing a very simple strlen "int lala(char* s){ int l = 0; for (;*s;++s,++l); return l; }" it failed with some weird errors.
So, eh, i don't think Eclipse CDT is it :-P.
You'll have to set paths on the installation or project so it knows where the relevant libraries and headers are. You won't configure it all correctly in the first week.
If you do give it a go, use a makefile project. If you're using something else to build, just have the call to that in the Makefile and nothing much else. Maybe it does cmake etc now? Haven't tried. I only use it occasionally nowadays. Brilliant for any refactor.