A follow-up posting, from Frederick Barachant to the same thread, had another
good idea:

"And what if the editor created non guarded folds for each custom code that
would be used to fill the right things under the hood?
Something like a "pre-init' marked fold before a component which, when edited,
would fill the pre-init in the interface. If the component is
moved/changed/whatever, the code could be moved/changed accordingly.
It would 'just' mean that the editor would have to be aware of modifications
inside specific folds. Not only that would be nice to everyone, but also it
would lower entry barrier to such code, make it acceptable to people that would
like to edit more of the code simply, without having to go through the
trees/tabs/scrollerbars.and maybe be enough so people whine much less on guarded
blocks..."

i think that should to have some option for disable the feature(Guarded Block).

crued: thanks for adding my contribution, you saved me some clicks. :)
I have one thing to add to what i said in the mailing list. I always hated the
custom code frame. It is modal, thus you can't navigate through existing code
for documentation or code to copy/paste and you don't have all the features of
the editor. All this makes the edition of code for those parts a pure pain in
the 4ss.
Going through folds would at least permit us to edit those parts in a much more
natural way. Natural for us and smoother for you, i believe.(but please pardon
my complete noobness in the netbeans API)

Exploring how to ease the custom code editing, we realized the easiest way is to
provide a dialog showing complete code for a selected component and allowing to
insert and edit custom code by providing empty lines between the lines of
guarded content. This brings all custom code editing to one place (includes
custom code for property value, pre/post code for properties, and various
pre/post code for the component itself) and makes the navigation easier.

Trying to do this in whole initComponents method would be overly complex to
manage, and unclear how to invoke/hide in the source editor (the editable folds
could not be enabled all the time, and also could hardly be non-modal).

Allowing the editing on the level of components in a dialog seems a reasonable
compromise. It is not like editing the code in the editor directly with no
restrictions, but it makes the custom code management much easier. Here I'd like
to stress that almost all code modifications/additions can be done *outside* the
initComponents method, with full editor features, completely under user control.
There are really just few cases that require to modify the initComponents method
code inside, and quite rare require to write some bigger chunk of code there. So
the goal is not to provide the full featured editing experience for the custom code.


The best thing is that the code customizer dialog has just been integrated to
6.0 dev build :) (Not necessarily in the final shape yet.)

The dialog can be opened from context menu on selected component ("Customize
Code") and it allows to edit all aspects of the generated code (all types of
custom code, name of the variable, type of the declaration, etc). It also allows
to select other components without leaving the dialog.

One more thing we will consider is allowing to invoke the code customizer from
the source editor directly. That would be nice. (That's why I keep this
enhancement open for now.)

Tomas, will work be done with refactoring when renaming variables?  I ask
because another issue I've been planning a bit involves variable renaming and
hooking form into refactoring.

I think I filed a similar issue re this before;  couldn't the editor be smarter about *inserting* into guarded blocks without explicitly adding blank lines the way 
the mobility pack does.  I.e. user presses enter in guarded block and they get a new line they can type into.  After all, it's modification of the generated code 
that's problematic;  not insertions.