The basic problem is that ToggleBreakpoint is enabled/disabled based
on the
focus being on a debuggable file in the built-in editor.  When using the
external editor, the NetBeans focus can be anywhere, and normally will not
be in the miniscule Source Editor window.

To work around this problem, we now requestFocus for the (dummy)
JEditorPane
associated with the file which is open in the external editor whenever we
get an EVT_keyCommand.  This mostly works, but there is still a problem
when switching buffers in xemacs.  NetBeans gets no notification of buffer
switches, and there is some kind of race condition when we requestFocus()
on a pane which is not the current pane in the built-in editor that makes
the ToggleBreakpoint action happen in the *old* file.

This will all be fixed with the Actions re-work (see issue 17597).

Closing this issue and filing a new one for the "changing buffer" problem.

The fix is not viable, since focus behavior is dependent on
the window manager.

We need a solution that does not depend on focus behavior.
We need the new Actions framework.

Here's an alternative idea. (Which I don't like, but....)

Breakpoint Toggling in the editor is currently performed not
by the ToggleBreakpoint action, but by a breakpoint performer
that's written in the editor kit.

Since breakpoint toggling is critically important in usage of
the idea, for this release perhaps we can write our own breakpoint
toggler?  E.g. we add our own toggle breakpoint menu item, and
when it's run in emacs (or vim) the external editor knows which
data object this toggling is associated with (the current buffer
when the action was performed). Then we do the code
which achieves breakpoint toggling for that dataobject and line:
(This is from the java module's JavaEditor class) :

      /* This method is called when parent window of this component has focus,
        * and this component is preferred one in it. This implementation adds
        * performer to the ToggleBreakpointAction.
        */
        protected void componentActivated () {
            try {
                final Debugger debugger = TopManager.getDefault ().getDebugger ();
                ((ToggleBreakpointAction) SystemAction.get (ToggleBreakpointAction.class)).
                setActionPerformer (new ActionPerformer () {
                                        public void performAction (SystemAction a) {
                                            int lineNumber = NbDocument.findLineNumber (
                                                        support.getDocument (),
                                                        getEditorPane ().getCaret ().getDot ()
                                                    );
                                            Line line = support.getLineSet ().getCurrent (lineNumber);
                                            synchronized (this) {
                                                Breakpoint breakpoint = debugger.findBreakpoint (line);
                                                if (breakpoint == null)
                                                    debugger.createBreakpoint (line);
                                                else
                                                    breakpoint.remove ();
                                            }
                                        }
                                    });
            } catch (DebuggerNotFoundException e) {
            }

As you can see, it just looks up the Line object, checks with
the debugger if a breakpoint is located there, and if so, removes
it, otherwise adds one.

Good idea for the interim.  I have it almost working (it gets the line
number wrong), so
I'm hopeful that it'll work with a little more debugging.

Found the bug.  The hack now works.