Which D IDE do you use?(survey)

[H. S. Teoh via Digitalmars-d]

On Fri, Apr 10, 2015 at 07:34:35PM +0000, Idan Arye via Digitalmars-d wrote:
> On Friday, 10 April 2015 at 19:19:38 UTC, Adam D. Ruppe wrote:
> >On Friday, 10 April 2015 at 19:08:13 UTC, Paulo Pinto wrote:
> >>- Move a method to another class located in another module, while
> >>updating all references to it, including module imports in the new
> >>file
> >
> >Cut the text out of one file, paste it in the new one, compile and
> >fix what the compiler complains about.
> >
> >...ditto for the others.
> >
> >
> >I admit this takes a few more minutes than an automatic ide thing
> >might, but it isn't that big of a bother to me because the compiler
> >errors combined with vim's "repeat last command" hotkey makes it
> >fairly quick and painless. When I run make from inside vim, it jumps
> >to the file and line the compiler spits out, so I can do a quick
> >"cwnewname" then f4 (my hotkey to go to the next error) and ., repeat
> >until done.
> 
> This - and also the fact that Vim's macros combine very well with
> modal editing. It's very easy to record a macro that does that
> specific refactoring bit in a specific place, and then jumps to the
> next place. After that, it's simply a matter of running that macro
> over and over until the refactor is done.

Which is extremely easy to do because Vim has built-in "repeat the next
command n times" facility. Something which IDEs lack -- because they can
only work at the abstraction level they were designed to do, whereas Vim
is actually its own language, and is thus able to express abstractions
its designers may not have thought of.

This is the inherent power of language, that no amount of clever
pre-baked set of functionalities can have. The only reason IDEs can do
complicated refactorings automatically, is because somebody hard-coded
that refactoring algorithm into the IDE code. Tell it to do something
else that it doesn't have built-in facility for, i.e., something that's
outside its set of prebaked algorithms, and it falls down flat.  A
language-oriented program like vim, OTOH, while it may not immediately
have all the end-user bells and whistles that modern IDEs have, *does*
give you the tools for building higher-level abstractions that can go
far beyond what its authors conceived of. This is achieved by giving you
the raw materials and tools -- regular expressions, repetition, macros,
etc., that are not confined to what the authors thought they would be
used for, but are expressive enough to go beyond that.

Sure it may take some effort to figure out, but at least, as the adage
goes, "easy things (things the authors thought of) are easy, and hard
things (things the authors didn't think of) are possible". For most IDEs
I've seen, "easy things are easy, but hard things are not possible". Sad
to say, sometimes even said "easy things" are relatively hard, or
inefficient to use (e.g., click through n levels of obscure nested menus
to find that one well-hidden item).


T

-- 
Only boring people get bored. -- JM