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!
