[sf-perl] Debugger goodness

[Joseph Brenner]

Quinn Weaver <qw at sf.pm.org> wrote:

> ... but then you'll eventually think, "I want to do x.  There should
> be a feature to do that".  So you'll run
> 
> M-x apropos
> 
> and search for a name that sounds reasonable (like "compile"), and,
> sure enough, there's a hook for running a compile process.  

Compare to using perl, where CPAN almost always has several 
modules that do (something like) what you want.

> The complete documentation for the command pops up, as Joe demo'ed,
> and you can run it or even jump to the source.

As far as documentation goes, elisp got one thing right that
perl didn't: there's a documentation string that's part of 
the function definition.  That's what you see when you ask 
for help on a function. 

One thing that perl got right though, is the way it's so easy 
to write documentation for an entire package using pod.  In 
the emacs world you're supposed to learn the "texinfo" format, 
which is just enough of a hassle that many things go
undocumented.  

(The solution that I use, I picked up from Ilya Zakerevich, the
author of cperl-mode: create some dummy variables with *really
long* documentation strings.  Essentially we abuse the "help" 
system, and get it play the role of the emacs "info" system.)


There are a lot of comparisons that can be made between emacs
and perl.  Both use interpeter/runtime engines, executing a 
dynamic language with built-in garbage collection.  Emacs
defaults to interactive use, and perl defaults to
non-interactive, but there are ways that either of them can
cross that line.


> Pretty much any esoteric feature you could want is already
> implemented, probably in the code that ships with Emacs, and it stays
> out of your face until you reach for it... but when you do, it's just
> there.

Well sort of.  One of my slogans is "With emacs, every typo is
a learning experience."