D IDE

[ShadoLight]

On Wednesday, 5 September 2018 at 13:11:18 UTC, Jonathan M Davis 
wrote:

[snip]

>
> 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.

True, which is the reason I was referring to the "the equivalent 
Vim/Emacs structure" provided (possibly) by plugins in Vim [1] 
and Emacs [2] to manage projects/solutions.

It anyway appears that Vim/Emacs are often extended by plugins, 
and this will be the only way to have some project manage 
features.

[1] 
https://stackoverflow.com/questions/1119585/vim-is-there-an-easy-way-to-manage-visual-studio-solutions-makefile-projects
[2] https://github.com/bbatsov/projectile

I maintain that it is not practical trying to duplicate this in 
your editor of choice except if the amount of time you will save 
(from increased productivity) exceed the time taken to do this. I 
maintain that for bug fixing/support in a big organization this 
will hardly ever be the case.

But even if you avoid this step and can build/run/test from the 
command-line it may not be optimal in certain debugging 
scenarios. See next point.

>
> 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.
>

Right, but depending on your type of debugging there is some 
things which just make more sense to do from right inside the 
debugger. If you hit a data value break-point or such on an 
attached debugger you can just double-click the line in the stack 
trace to go to the appropriate line in the IDE editor. No need to 
switch tasks to Vim/Emacs, do a go-to or whatever to get to the 
same place. The type of debugging I'm talking about is not your 
'single step' variety.

I sometimes wonder if the Vim/Emacs 'affectionados' spend so much 
time mastering their editors (which by all accounts have a steep 
learning curve), that they forgot that IDE development did not 
stagnate after they left!

> 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.

Agreed.

>
> 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.
>

Again, it depends on what you mean by 'editing'. If you are 
referring to coding where you are developing from scratch, then 
sure - I agree. You will be doing a lot of coding before building 
the 1st time. And then the build will fail for the 1st few times 
with initial bugs. And then (unit/CI) testing will show up some 
more bugs, which will necessitate more changes/fixes. Repeat and 
rinse until the project is finally delivered. In this phase the 
editor of your choice is really nice/handy (if you can handle 
everything from the command-line).  I suspect this is your (and 
Nick's) primary use-case. And is maybe the primary use case for 
the majority of D contributors.

But the whole point of my post was to point out that this is not 
the only use-case for some of us. And in some of these other 
use-cases IDEs are actually superior to editors.

For another example IDEs are also in some ways a 'standard' 
inside big organizations in a way that any editor cannot be - the 
lowest barrier of entry to get new members up to speed in a team. 
And for some languages (Java/C#) you give up a lot by not 
developing inside an IDE. In fact, for Java and C#, the 
appeal/power of the languages is in many ways directly related to 
the IDE! Now throw in mixing C# with C++ (or even D) 
development... I'm sure you get my drift!