Other than that, however, I'm afraid that there is little PHP/whatever support at this time, and I'm strictly against adding any. The same goes for Java (with gjc, Java files are compileable, but that's it) or anything else.
[...]
We have serious deficiencies in the design and functionality of several major components, and instead of addressing them, we add hacks to "support" things that are not the IDE's actual objective.
We double and triple the amount of work, and we end up with a program that will never be finished and will never work in a satisfying manner for the one thing that's its main objective.
Yes, I'm aware that adding shiny features is more fun than properly implementing things that don't work, and a program that can do everything is ultra-cool. But it's ultra-counter-productive too.
I couldn't DISagree more. I realize that I'm not involved in the development or maintenance of C::B in any way (yet?), but I'd really like to use it as my primary production tool, as it seems to be the closest thing out there to what I believe an open source IDE should be. (And, yes, I do understand that what this all boils down to is personal preference.)
A typical day for me has me working on numerous projects, utilizing VBScript, PHP, HTML, CSS, and sometimes some strict VB and C or C-based derivatives. Most times, these projects are open simultaneously, and switching back and forth between editors and project managers is not only tiresome, but also frustrating, and is definitely taxing on the resources of any development machine, regardless of the hardware spec. That nifty "can't-live-without-it" feature that exists in one editor may be in a different place or not exist at all in another. To be quite blunt, and this is by no means anything personal: if there were a better suited open source IDE that looked at all like it was going in the direction I'm interested in, I'd likely not be here. That's just part of being a professional -- finding the right tool for the job.
My own personal view is that a great IDE will have all the bells and whistles one could ever dream up, but would be neatly contained and out of the way unless/until the user went looking for it. I don't need the engine mounted on the roof in order to know it's a car, but if you're going to tuck it away in the engine compartment, I definitely want to know that it's got more than one cylinder, and I want to be able to tinker with what all eight of them can produce.
If supporting multiple language syntax was not a part of the original design, then why use the flexible lexer engine at all?
At the same time, I do appreciate your statement that hacking away to get new functionality should not take precedence over fixing existing bugs or finalizing half-implemented features, and THAT is a concept I most certainly respect and to which I wholeheartedly agree.
Fix what's broke... Then add more blinkin' lights.