First, let me say that the term "IDE" is very poorly defined (see my old discussion ) and the individual requirements vary immensely.

The beauty of Emacs is its scalability as a weapon to attack problems, from light dagger to heavy battle cruiser. Otherwise I would recommend something like Komodo.

perldb

> Never used it inside Emacs, (and hardly outside it)

Neither do I, well as long as I have full control of the code. Stepping with breakpoints can be very handy with foreign code

> Do you have the ability to jump from a debug line to the source file?

The source file is always visible and the current line marked.

like here http://www.khngai.com/emacs/emacsperl.gif

There is also perldb-ui.el but I haven't tested it yet. see perldb.png

flymake-mode

> have major issues with these, since my setup (everything is in local::lib), gives me "module not found" errors.

that's not the editors fault, you either have to define lib with the of perl -c command like you would on the command line or set up use lib properly.

Yasnippet

> Not my style of programming,

Well I'm very critical of boilerplating, most problems could be better solved with appropriate modules.

But textmate's snippet format also comes with the ability to include interactive code (elisp or Perl calls or...) and choice menus (like e.g. 'rw', 'ro', ... for Moose attributes)

It offers an open standard for extensions which is editor agnostic.

Auto Complete

> I know some also like company-mode,

I have to look into this...

> which can be used to force a code-style across the company (hence the name), which is a good counter argument to those that claim perl is unsuitable for large companies/projects.

Doesn't this contradict your later claim that Perl doesn't need an IDE??? ;-)

ECB = Emacs Code Browser

> Is this really beneficiary for perl programming?

1. Many people identify IDE with a certain Eclipse_(software) "look", with different panes. The graphical experience of different panes gives them the feeling of uncharted territories to explore.

Having a pane where all subs are listed is certainly beneficial for a beginner who doesn't know how to activate imenu .

And we have to admit that in the learning phase clicking on an icon and experimenting is easier than reading documentation.

2. ECB is neatly addressing the second biggest problem² of Emacs, the window management (it took me ages before I discovered winner-undo). You can define your personal layout(s) and the editing panes will never be destroyed or divided. All compilation output and occur parsing and other things will be directed to the compilation window only.

3. ECB comes with an overhead but I only activate it when needed (please try to use something like Komodo on a netbook or over SSH on a TTY) and I switch between different self defined layouts (like one showing the currently important file from my testsuite with result).

Vision

> As for the vision, I just don't thing perl needs an IDE.

Emacs is not an IDE it's an IDE construction set!

TIMTOWTDI and heaving a bundle which can be easily customized for your personal needs could be beneficial for Emacs users and the Perl community in total.

I don't have hubris to solve anyone's personal requirements, I want to have the basis for a solid discussion.

==== footnote

²) the first being the byzantine key bindings

> which can be used to force a code-style across the company (hence the name), which is a good counter argument to those that claim perl is unsuitable for large companies/projects.

Doesn't this contradict your later claim that Perl doesn't need an IDE??? ;-)

I like your line of reasoning. As I should state, this boils down to personal preference. I have worked in languages and technologies that are near unusable without an IDE. In many ways, it's also because the environment (read: Windows) doesn't support many of the userspace tools readily available to *NIX users, like grep, or has no readily-available way of printing out data-structures to STDOUT (e.g. Data::Dumper), and if and when you do inspect structures, they are unreadable.

Perl, OTOH, can dump any structure at any point, and you can always figure out "what does perl think X is" which is basically what you need debugging for. There's also less need of the "Intellisense" feature since you're not dealing with tens of thousands of classes and methods, and the libraries you choose have usually a simple and well documented API (yey CPAN Kwalitee).

As for company-mode and code style, I don't think this is an integral part of an IDE. It's more of a feature of existing IDEs, and you can accomplish the same in many other editors and tools, without having to lock-in to an IDE.

Emacs is not an IDE it's an IDE construction set!

That is definitely *the* selling point of emacs, and you can construct it to better suit your needs. Whether you want a debugger, or a code-style, or some sort of CI, it's all available in emacs. You can also integrate emacs with a bug-tracker or similar, and I again point to Org-mode as an excellent project management tool. Also, it has one of the better git integration with magit, which can be seriously helpful in development.

Come to think about it, I would say that, while perl doesn't need an IDE, software development of large projects or in a large company does need a lot of tools to assist the streamlining of the development, and emacs has all of those, and then some.

Principle of Least Astonishment: Any language that doesn't occasionally surprise the novice will pay for it by continually surprising the expert

> I have worked in languages and technologies that are near unusable without an IDE.

I had a colleague once who was considered a "Perl expert".

His work pattern was pretty consistent:

When assigned a new task, he'll

• Fire up Komodo IDE
• As a start: rename an older, similar but incomplete script from the same problem group
• Google for a missing part with "Perl" included in the query
• Paste new chunks and wait if Komodo complains by underlining some line
  ( something like "fly-make perl -c " is activated by default here)
• Make some adjustments, always waiting if lines are underlined
• Repeat the googling process with other missing functionality
• Occasionally run it from the editor
• If it fails add a break point by clicking the line, it now runs under the debugger and stops there
• If inspecting the variables which are shown in a extra pane don't reveal problems stop at the next break-point
• In 80+x % cases he's "successful" with this strategy
• In the other 20-x % cases he came ranting into my office saying that Perl is totally inappropriate for the job ...
  ... and that obviously Python, Ruby, * (fill it in) is FAR better

OK you might say this is not a real "expert" ...

... he doesn't even know how

• to read documentation
• to use perl -c
• to start the debugger and use it's commands
• and other things

But management - which is non IT and has no clue about programming and the long term costs of boiler plating and cargo cult - will say

• that our group has a cheap company license for Komodo
• he gets most his jobs "done"
• that the investment was obviously justified.
• and he can't be blamed for Perl's complexity

Needles to say this "expert" will tell the world that:

Perl is near unusable without an IDE like Komodo.

Punchline? Already one week after I started in this project I knew Komodo (V6 back then) better than the rest of the team together. To be fair ... with all my Emacs experience I knew what to look for.

For instance I tried to help them to switch the internal REPL from Python to Perl - for vain.

That much about bundles with useful defaults.

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!}

The perldb works really well inside of emacs: you get a two window display, one window shows the shell/REPL area where you type debugger commands and the other shows the code it's tracing, with a "=>" superimposed, pointing at the next line that will be executed.

A screen shot: http://obsidianrook.com/devnotes/talks/perl_debugger/Images/emacs_perldb_big_color_screen.jpg

It's not the main way that I debug things, but if I'm feeling completely at sea about what some code is doing, playing with perldb is one of the tricks I might used to get oriented.

The "m" command is particularly interesting: it gives you a list of all available methods on a class or object. It's not very easy to get that information in any other way.

I wrote a tutorial on using it a long time ago (it's a bit dated, and probably a bit long).

The perldb works really well inside of emacs

That's very nice to know. I've probably never used the perdb in my work, but I do appreciate its existence and that it works well within emacs.

Principle of Least Astonishment: Any language that doesn’t occasionally surprise the novice will pay for it by continually surprising the expert

> works well within emacs.

To be fair, Komodo's debugger integration is better.

You can click on a line in the source code to add a break-point ... and IIRC (?) the next run will be automatically executed under the debugger then.

This could be implemented in Emacs of course and I haven't tried out alternative packages yet.

Simply because debugger is very low on my priority list.

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!}

Speaking of REPLs, I've been using Reply for a good while now (especially with plugins,) and thankfully there's an Emacs frontend for it.

Hey Joe, nice to read you again! :-)

You might want to put your ink into [...] to make it clickable.

I wanted to "borough" one or two of the quotes from your old talk if it's OK! ;-)

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!}

Sure, you use whatever you like.

Yeah, clearly I haven't been around here lately, I've forgotten the local mangled version of html.

These two modes are very similar and do basically the same.

Their usefulness heavily depends on the configured provider back-ends (so called "omni-completion" )... and from what I see both don't bring notable Perl support out of the box.

At least plsense builds on auto-complete to provide Perl omni-completion.

But if you have details on why to prefer the one over the other, I'd be interested to hear them.

> I prefer flycheck to flymake,

IMHO fly-make is build in, that's why I use it. The intention of my talk is to give an overview, people are free to experiment and contribute better solutions.

> I prefer flycheck to flymake,

So I tried it out via package install ( which is very cool compared to former times, installing el-packages with dependencies like CPAN does -> MENU > Options > Manage Emacs Packages )

my first impression was bad it was pretty slow ... till I realized that it's also running perlcritic in the background.

after temporarily deactivating Perlcritic ( M-x customize-group flycheck > Flycheck Checkers ) it worked smoothly and looks easier to maintain! :)

Will still have to look into optimizing the appearance ...

I occasionally have my windows-emacs hanging several seconds when using flycheck

according to the maintainer

> ... I am sorry, but as said before we do not support Windows. As such, please understand that we do not want to document Windows-specific bugs and issues in our documentation.

I think it's safe to resort to flymake then.

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!}

update

probably my perceived problems with perlcritic blocking were just Windows related...