Re: D IDE

[Ecstatic Coder via Digitalmars-d]

Except that you don't have projects or solutions with something 
like vim or emacs. There is no structure specific to them. You 
can set them up to do the build from inside them, and with 
emacs, you can run gdb inside it if you're on an appropriate 
platform, but you're not going to have a "vim" project or an 
"emacs" project. That whole concept is an IDE thing. They edit 
files, and they can do that perfectly fine regardless of what's 
being used to run the build or whatever other tools are 
necessary for the development process.

If I'm in a situation like you describe, then I usually set it 
up so that I can just run the build and tests from the command 
line and not even bother opening up Visual Studio. VS projects 
actually have a way to do that. You don't actually have to open 
up VS to do any building. And if I really need to open up VS to 
run the debugger, then I'll do that, but I won't use VS for 
anything that I don't have to use it for. And in my experience, 
the debugger is pretty much the only thing that would typically 
require actually opening up VS.

There is no reason to muck with the build process or source 
control stuff in order to use vim or emacs. That stuff can 
pretty much always be done from the command-line using all of 
the standard tools that everyone else is using. Just because 
most developers would use the IDE to run the build doesn't mean 
that it's actually required for it. If it were, then stuff like 
automated builds wouldn't be possible.

Regardless, I use vim for editing code. And if I'm actually 
forced to have an IDE like VS or Eclipse open because of some 
tool that has to be run from inside for some reason (which 
aside from the debugger is rarely the case), then I'll have the 
IDE open for whatever it has to be open for. But I don't use 
the IDE for editing code, because that would be a horribly 
inefficient way to do go about it.

- Jonathan M Davis

+1

What must be absolutely standardized is what is *shared* across 
the members of the team (code presentation, tabs, naming 
conventions, build process, versioning, test and deployment 
procedures, etc etc).

But as long as the coding standard is followed, obviously any 
code editor should be fine if it makes you more productive.

For instance, even for contract work, I use Geany for all my 
developments.

And a portable IDE like Geany is especially useful when 
developping *crossplatform* C++ multimedia applications which 
must be edited and tested both on Windows, MacOS and Linux.

It is the perfect companion to cmake, behaving exactly the same 
whatever the platform (editing, find and replace, find in files, 
macros, settings, etc).

And indeed you can still open your project in Visual Studio when 
you need to use a Windows debugger.

Personally I use Geany even for Unity game development, as Unity 
allows to define which editor should be used to show the 
erroneous line of C# code when double clicking onto an error 
message.

Geany is great for that too, as it opens often much faster than 
other IDE...

So my point is, as long as all the shared team standard 
procedures are respected, I fon't see why any company should 
decide which code editor *must* be used by all its developers...