Re: OPINION: What are the best Linux C++ IDE's out there?
From: Noah Roberts (nroberts_at_dontemailme.com)
Date: Mon, 18 Aug 2003 22:01:07 -0700
> Im Artikel <3F3FA5E5.email@example.com>, Noah Roberts
> <firstname.lastname@example.org> schreibt:
>>I did read your entire message and found little in the way of actual
>>argumentative content. I think I could summarize the entire thing as
>>"Unix development sux, you need an IDE". What is missing from this
> Nothing missing, so far ;-)
>>Any evidence as to why. Just saying that the command line
>>tools are obsolete is unconvincing, tell me why. Tell me why an IDE is
>>better and/or more powerful than the command line and a good editor.
> The omission of concrete examples was intended ;-)
> What would you like me to elaborate first, my criticism on the build process in
> general, or the benefits of an IDE? The IDE topic may be shorter to explain, so
> let me stick with it for now.
> The most important feature of an IDE is the integration of the compiler and
> editor. The compiler then can analyze all declarations in a project, and
> provide tables with detailed information about data types and other symbols for
> use in the UI. How else would it be possible to jump in the editor from the use
> of a symbol, to its declaration? This is one of the features, which I meant
> with code navigation.
This feature exists within xemacs, a text editor. Now, it is a rare
breed of editor for sure, but since your argument against Unix
developers not understanding the need for an IDE certainly puts this in
perspective. This is an ability my editor has, it has always had, and I
really don't use it a whole lot.
> Okay, there exist ways, using compiler created tables and grepping and ..., but
> such procedures require that the project compiles at all, what's not normally
> the case /during/ editing, requires a recompilation after most modifications,
> and it will be slow and block efficient editing in most cases. An integrated
> compiler at least must be capable of parsing parts of the actual code,
> gracefully ignore incomplete or erroneous parts of the source code, and provide
> information about the source code in the first place.
The only IDE's I have seen provide a simple integration with the
compiler as you described in the previous paragraph. You get a bunch of
errors and you can click on them to go to the code. They don't
gracefully ignore anything and behave as badly as any other compiler
when given erroneous code.
Now, there is the exception of Visual Basic in which the editor itself
interprets the code as you type it and will not let you enter in
something that is not syntatically correct. I find this a major pain in
my ass as I often find myself in the middle of typing something when I
remeber that some code elsewhere must be changed...VB will not let me go
there until I finish or delete the code I am working on. I really hope
that it is not this kind of behaviour you are advocating.
> Code navigation also allows for extended context sensitive help, apart from
> external fixed help or info files, since it makes immediately accessible all
> information near the declaration of any symbol in source code. It also will
> find the only appropriate declaration, when the same name is used in various
Context sensitive help is very easily done and integrated into many
editors. For instance when I request the "man" feature in xemacs it
often provides me with a default which is based on a symbol next to the
> The same considerations apply to code completion, where the UI must be able to
> present context sensitive lists of possible symbols, from which the user can
> select one, instead of keying in the full and probably inappropriate or
> misspelled names. This is a widely appreciated feature, even the bash allows
> for such shortcuts to filenames.
Any decent programmer editor does as well. In mine I have this feature
keyed to the hotkey sequence "M-/".
> Please note that all these features are not bound to a GUI, which often is
> associated with the IDE term. Just during editing it's not desireable to move
> the hands off the keyboard, all that should and can work without a mouse in the
> first place. Consequently any appropriately extensible text editor can be used
> as the base of an IDE, as already mentioned and suggested by other
> contributors. I only want to explain and prove why the existing tools often
> deserve modifications, before they really fit together in an IDE.
So far you haven't mentioned much of anything that goes beyond the basic
programmer's editor. The compilation error navigation was the only one
that I find unique to certain advanced editors.
Maybe the simple fact is that you are unfamiliar with the tools that are
used in Unix development, hence the belief that there is a need for
IDEs. Unless you have something else you did not mention 99% of what
you think is only available in an IDE is actually standard in a decent
programming editor, like I said before.
Now, some people might consider Xemacs an IDE, and in fact there are
additions you can run that turn it into just that. Really though, it is
simply an extensible text editor. I have tried the IDE package for
xemacs and honestly did not like it any better than any other ide.