Before we touch anything, you need to make sure that your classes are compiled with support for debugging. Otherwise, many things will appear broken when you run the debugger.
To add debug support when you compile, you run the javac command with the -g option. With the JDEE you can also use the variable jde-compile-option-debug to hold all the variations for debugging you like. If you customize this variable through Custom (see Chapter 10), just choose the "all" option for which debugging information to include. (Optionally, you can be more specific and select from the three types of debug information: Lines, Variables, and Source.)
We'll look at the jdb route just to get you started. You can start the debug session by typing M-x jde-jdb. The same variables that control the starting directory and main application class are used for debugging purposes.
After you have launched the debugger, you can control the debug process in a number of ways.
• Interact directly with the jdb process in the *debug* buffer. Here you can type any command that you would normally give when running jdb.
• Use the Jdb menu. You have all the usual debug options available: step into/over, continue, toggle breakpoint, and so on. This is a bit more limited than the first approach, but easier to manage if you're new to jdb.
• Use keyboard commands while you're in your source buffer. These commands are even more limited than the menu options, but give you really quick access to the most common tasks (namely stepping and break points). Table 9-8 shows the commands that are available while you're in a source buffer.
Table 9-8. JDEE debugger controls
| Keystrokes | Menu item | JDB command |
|---|---|---|
| C-c C-a C-s | Step Into | step |
| C-c C-a C-n | Step Over | next |
| C-c C-a C-c | Continue | cont |
| C-c C-a C-b | Toggle Breakpoint | stop in/stop at/clear |
| C-c C-a C-p | Display Expression | |
| C-c C-a C-d | Display Object | dump |
Figure 9-4 shows a simple application running in debug mode. Notice the small black triangle to the left of the Java source code in the upper buffer. That's the debug cursor that lets you know where you are in the file. It tracks the commands you issue, whether by directly entering jdb commands, by menu option, or through the keyboard.
Figure 9-4. Debugging a Java application with jdb
9.5.9 Learning More about the JDEE
Clearly, there is a lot more to the JDEE than we can cover here. The package you download comes with some good documentation and several user guides for the basic JDEE and various options like the debuggers. The JDEE web site, at http://jdee.sunsite.dk, is a great source of information, too. As you would expect from an Emacs package, you can customize everything. Those customizations are stored in your .emacs file so you can tweak them by hand (or at least peek at them).
The best approach is to install the JDEE and start coding with it. If you find yourself saying "There should be a way to do X," get out the documentation. Chances are there is a way to do X—usually with more options than you could hope for!
9.6 Perl Support
Emacs has Perl support. Indeed, much like Perl itself, there are multiple ways to get things done—in this case, multiple Perl modes: the classic Perl mode (which comes up by default) and the more popular CPerl mode.
You should have a version of CPerl mode built right in, but you can also pick up the latest release from CPAN (the Comprehensive Perl Archive Network) online at http://www.cpan.org.
You can add one of the following pairs of lines to your .emacs file to make sure CPerl mode is invoked rather than Perl mode
;; load cperl-mode for perl files
(fset 'perl-mode 'cperl-mode)
;; or maybe use an alias
(defalias 'perl-mode 'cperl-mode)
CPerl mode is mostly like cc-mode with respect to motion and other programming language features. It also includes fun debug operations. You can start the debugger with M-x cperl-db. You'll be prompted to verify the debugger command and then be dropped into a split-screen mode. One buffer allows you to drive the normal perldb environment with all the regular commands you're accustomed to using in the Perl debugger.
The other buffer shows your script and follows along as you work through the debugger. It tracks the line you're about to execute as you issue commands in the other buffer. It's amazing how quickly you grow to depend on having such tools available while you're developing scripts. It is worth trying out if you've never done it before.
9.6.1 Perl Caveats
A big reason we wanted to mention Perl mode here is to highlight a few caveats. Perl is an amazingly expressive language much more akin to the idioms found in human languages than just about any other computer language out there. That expressiveness can cause problems—especially when considering the expressiveness of regular expressions.
Perl supports all sorts of "funny" variable names like $' and $/. CPerl mode boasts the use of a syntax table to help understand most of Perl's odd and occasionally disruptive verbiage. The older Perl mode has no such trick up its sleeves and suffers under many circumstances in the font-lock and indentation realms. This is one of the main reasons to make the leap into CPerl mode.
Even with that syntax table, though, you'll probably find some combinations of variables and strings that give Emacs headaches. Sometimes restructuring your code will help, sometimes not. The important thing to remember is that it won't harm your program at all. It might make things a bit less readable, but the script itself should run just fine. And if it doesn't, you can always launch the debugger to find out why!
Here are some parting .emacs thoughts for you Perl programmers. These lines select cperl-mode as the default and make sure the syntax highlighting is turned on. These lines also turn on folding (outline-minor-mode in the snippet below). Folding allows you to "hide" chunks of your code, such as functions where the body of the function is "folded" into the name. That can make it easier to get a grip on everything that is going on in the file. Try it—it can become addictive!