[sf-perl] [poll] What Perl IDE do you use?

[Steve Fink]

Just to clarify what is available with emacs + perldb:

On Sun, Apr 17, 2011 at 4:36 PM, Dan Dascalescu <ddascalescu at gmail.com> wrote:
> The reasons I prefer a *real* IDE vs.a text editor + perl -d include:
>
> * live syntax highlight and underlining of errors as I type them

Live syntax highlighting works. Only a few errors are caught
immediately (mismatched parens, unclosed regexes, etc. -- simply
syntactic errors that are relevant to the highlighter.)

> * ability to step through the code in the editor window with such
> syntax highlight. Can you do that in vi(m) or emacs?
> http://www.emacswiki.org/emacs/DebuggingWithEmacs suggests you can't.

No, I definitely have that capability with perldb in emacs. What on
that page suggests otherwise?

> * ability to easily switch among multiple code editor tabs with
> different files that make up the project

So you like that the UI presentation is tabs? Because obviously emacs
and most other editors can have multiple files loaded at once. But in
emacs, you switch between them with command keys or dropdown menus --
is that the difference you're pointing out?

> * when debugging, if I figure out the cause of the issue is somewhere
> else in the code (e.g. in the caller sub), I can scroll the code
> window there and make the change. In perl -d, I only have a read-only,
> non-syntax-highlighted peephole vision of a few lines around the
> currently executing one.

Are you running perl -d in a shell inside emacs or something? perldb
certainly shows you the original (editable) source file, with syntax
highlighting.

> * display of watched variables as I step through the code

I think of this, and things like click-to-set-breakpoint and
hover-to-see-value, as the bread and butter of IDEs. Along with things
like a live stack backtrace display.

gdb within emacs can actually do most of this, though to use it I
think you really have to let it control the arrangement of your buffer
windows (panes?). There's some magic command that I never use that
splits your screen up into a source display, a debugger prompt, a
variable watch pane, a stack display, and I think something else. (Or
something like that; I never use it because having > 2 panes option
makes it much harder to use the keyboard to jump between buffers. If
you're ok with using a mouse and dedicating lots of screen space,
maybe it's usable.)

I don't know if the same is available for perldb. I doubt it.

> I understand that people stick with ancient editors due to the
> enormous investment in learning and configuring them. I also do that -
> I've been using the same two-pane file manager for over 15 years.
>
> But let's consider someone new to Perl, without prior investment. Are
> there objective reasons why they should *not* use a *real* IDE (Padre,
> Eclipse+EPIC, Komodo IDE)?

The two main reasons that immediately spring to mind are (1) emacs +
perldb are usable in text mode and across remote links in pretty much
the same way as they are on a local graphical display; and (2) emacs +
perldb (and vim etc.) are preinstalled everywhere. At least for the
types of things I do, those two reasons would mean that I'd have to
get comfortable with two completely different environments (an IDE +
emacs/perldb), and I haven't found anything compelling enough in any
IDE to make it worth it.

Which is not to say I'm anti-IDE. I started out with one, and hated
being forced to learn the text-only command-line way of doing things.
But now I'm very comfortable there. I still think that IDEs have the
opportunity to add in killer functionality much more easily and
naturally than editor-based tools -- and yet, nobody has really come
up with anything that is must-have. Well, with the exception of SVG
and CSS inspectors/debuggers, that is -- inherently graphical tasks
definitely make graphical tools worth using.