Trap Flash CS3 compiler errors and line numbers… in jEdit!

Love editing your Flash ActionScript files in jEdit, this site but want better debugging tools within the editor itself? Maybe you’d like to jump directly to errors indicated within your code without resorting to the Flash IDE?

Today’s tip just makes me plain happy.

placeLogo(‘jedit’); The result of today’s exercise promises to increase productivity dramatically when editing ActionScript using jEdit: Assuming Flash is running alongside the editor, stuff we’ll not only be able to test our current movie with CMD-ENTER (just as we did two months ago), but we’ll also be able to get a list of compiler errors and warnings to appear within jEdit’s errorList panel, and we’ll be able to click those errors to jump to the offending code — without ever having to edit any code within the Flash IDE itself!

It may take a few minutes to set up, but it definitely shows off the power and expandability of jEdit — while also providing a heckuva nice (and long awaited) feature for us cross-platform Flashers.


First, it’s time to gather the ready-made ingredients:

  1. The Console plugin for jEdit
  2. The ErrorList plugin for jEdit

You probably already have these, but if not, follow the instructions in Part 1 of this series to get them set up with jEdit. This article merely builds on the original “Test in Flash” macro we created back when we started all this.

In fact, I’ll start the hand-made stuff with a new Test_in_Flash.bsh macro that can be typed into jEdit and saved directly to your jEdit macro directory (again, see Part 1 if this is confusing to you):


// Save this file to your hidden ~/.jedit directory as "Test_in_Flash_IDE.bsh"
// This will cause the command to appear under the Macros directory as "Test in Flash IDE."
// You can then assign a Shortcut key (such as CMD-ENTER or F6 a la FlashDevelop)
// using jEdit>Preferences>Shortcuts>Macros
//
runCommandInConsole(view,
"System",
"rm -f ~/.jedit/flasherrors.tmp;
open ~/.jedit/launchers/flashtest.jsfl ;
sleep 2;
cat ~/.jedit/flasherrors.tmp"
);
// The following line just tidies things up.
clearConsole(view);
Source code for Test_in_Flash.bsh

The above code assumes you have a hidden folder named .jedit within your default user home folder (indicated by “~”), and a JSFL file (we’ll create it next) named flashtest.jsfl within a launchers subfolder of .~/jedit.

The macro’s operation is simple: It tells the Command Console plugin to execute code that first deletes a temporary file (if it exists), then launches the flashtest.jsfl within the Flash IDE. Next, the console shell waits a couple seconds to give Flash time to choke on any errors your code might contain, then it lists the contents of the new flasherrors.tmp which was generated when the JSFL file ran (more on this later). Finally, it clears the console to start again anew.

So what’s in the mysterious flasherrors.tmp file? It’s the output generated by the Flash compiler, in a format dictated by Flash itself. It’s generated by the ~/.jedit/launcher/flashtest.jsfl file, which should contain the following:


flash.getDocumentDOM().testMovie();
flash.compilerErrors.save(
"file://Users/USERNAME/.jedit/flasherrors.tmp",
true,
true
);
Source code for flashtest.jsfl

Man, I love the extensibility features of Flash! Thanks to JSFL, most of the hard work is already done for us.

Note: In the above code, be sure to replace USERNAME with your current system user name (The URL format used by the flash.compilerErrors.save() method does not allow for the “~” shorthand we’ve used elsewhere).

Confessions of a cheater:The output from the compiler is of interest to the ErrorList plugin, but not to us. Unfortunately, the ErrorList plugin does not actually monitor log files, but pays attention only to jEdit’s own “editBus” message system. We could write a proper Java plugin to send the info to the errorList, or we can simply do what I’ve done here: cheat and let an existing “editBus aware” plugin do the work for us.

The cat command in the beanshell (Test_in_Flash.bsh) script above does little more than spill the contents of the generated log file into the command console, which, coincidentally, is monitored through the editBus by the errorList plugin. Because the “spillage” is not much to look at, the last line of the macro itself simply clears the console view of the mess created by cat — but by then, both Console and ErrorList have already started conspiring together through the magic of regular expressions:

Now we just need to make sure Command Console recognizes the cat output so it can send a proper message to the ErrorList. We do this through the Plugin>Plugin Options…>Console>Error Patterns settings panel. Navigate to the settings and click the “+” (plus sign) under the list of Error Patterns. When you are prompted for a name, type “ActionScript.”

Next, type (or better yet, copy) the following regular expressions into the settings panel carefully:


Error Regexp:     **(E[^*]+)**s+(.*)?,s+Lines+(d+):s?(.*)
Warning Regexp: **(W[^*]+)**s+(.*)?,s+Lines+(d+):s?(.*)
Filename: $2
Line Number: $3
Error Message: $1: $4
Entries for Plugins>Plugin Options…>Console>Error Patterns>ActionScript

When you’re done, the panel should look like this:

Regular expressions to map error messages within Console plugin options

Press Apply to confirm the settings for the Console plugin.

Next, while still in the Plugins options panel, navigate to the options for the Error List plugin and ensure that “Automatically display on error” and “Show error icons in the gutter” are both checked. This will allow for instant notifcation once the macro has run successfully.

Once that’s done, there’s nothing left to do but test it: Open an FLA file in Flash and an associated ActionScript file in jEdit, and test the movie using your new “Test in Flash” macro.

If you have an error in the code (you’ll probably have to introduce one on purpose, as I’m sure your code is usually flawless), you should see something like the following suddenly appear in the jEdit errorList panel (which you may want to make sure you dock somewhere on the screen):

Errors displayed within jEdit Editor

If it’s not working… well, check your work, making sure you changed any usernames or filepaths to match those of your system (those presented here are particular to OS X, for instance). If you’re really stumped, drop a line and maybe we can figure it out together.

Happy coding!

facebooktwittergoogle_plusredditpinterestlinkedinmail

4 thoughts on “Trap Flash CS3 compiler errors and line numbers… in jEdit!”

  1. Hi!

    Your jedit tweaks are fantastic! Thanks heaps!

    However the one thing stopping me from moving over to jedit for actionscripting, is the fact that you cannot set “go to next word” and “go to prev word” as the os x default shortcuts: option-right and option-left. From what I can tell, jedit doesn’t recognise the option/alt key in osx.

    I tried recording go to next word as a macro and it looks like textArea.goToNextWord(false,false);
    and I tried setting that as a shortcut in system preferences > mouse/keyboard > shortcuts. But because jedit doesn’t recognise alt/option it wont work at any level.

    I see this bug has been reported in sourceforge, but not much action…

    Any other ideas how to fix this?
    Then jedit would be perfect!

    Thx,
    Sebastian.

  2. Thanks for the kind words, Sebastian. As a Windows refugee, I tend to overlook the Option keys myself — I naturally gravitated to CMD-right and CMD-left to move from one word to the next, and only now realized that the OPTION key is indeed “dead” to jEdit.

    Apparently, you can change the behavior of modifier keys using the “setModifierMapping” method within a macro (found this info here, but sadly, I’m not sure what to do with it from there). I’ll look around, though, as I assume this will probably aggravate more people, too.

    Thanks for the head’s up!

  3. yeah i found the setModifierMapping macro too, however no matter what order you put the masks in, alt never works.
    KeyEventTranslator.setModifierMapping(
    InputEvent.CTRL_MASK,
    InputEvent.ALT_MASK,
    InputEvent.META_MASK,
    InputEvent.SHIFT_MASK);

  4. finally found out why setModifierMapping wasn’t enough to get alt working! you also need to set these two lines:
    Debug.ALT_KEY_PRESSED_DISABLED = false;
    Debug.ALTERNATIVE_DISPATCHER = false;

    I found this info here: http://muzso.hu/node/4304

    yay AS editing here i come.

Leave a Reply

Your email address will not be published. Required fields are marked *