An API enhancement request, not a defect. Petr, please evaluate and re-assign as
appropriate.

It has nothing to do with base editor, you are asking for structural events on
the java level, so passing to the java editor.

I agree this is a Java Editor event enhancement request.

We need this Enhancement ASAP available in NB4.1, for our release. We have a 
broken functionality in our product, due to the fact we are not listening to 
Java Events to make correct judgement of certain other Nb Events. 

For Eg:- 

We would like to know that when a documentListener.insertUpdate() callback 
happens, what is the java event that caused it. Is it the 

* Undo operation
* Block comment/uncomment
* Adding "New Methods", "New Fields" etc.,

Based on this information, we can do certain specific action.

There is (and was long ago) an API for listening to added fields, methods, etc.
(you can use org.openide.src for that).
For undo and comment/uncomment events this is an editor issue. Anyway, I doubt
it could be done for 4.1 - we are feature frozen, one week before high resistance...

There is currently no specific way to listen for comment/uncomment actions
triggering. What is actually the use-case: listen for comment/uncomment action
triggering or finding of the text bounds of where these actions operated or
being notified about line-comment tokens creation/destroying?

-I will try to look for the API for listening to added fields, methods, etc.
(you can use org.openide.src for that), as suggested.

-How do I listen to undo operation.

-use-case for listen to comment/uncomment action: 
1) To know that comment/uncomment happened
2) When this happens I would like to find the text bounds of where these 
actions operated.

I am changing the priority for this bug to P1, since our product currently has 
an outstanding P1 bug which depends on the NB4.1 fix for this issue.

I'm sorry but we will certainly not make the things that you request into 4.1.
There will be a high resistence mode starting the next week so it's too late to
think about any such API.
However you could get the requested functionality by replacing the default
comment and uncomment actions by your own ones. You can do that by doing an
org.netbeans.editor.Settings.Initializer and update the custom actions list.

public class MyActionsInitializer extends Settings.AbstractInitializer {
    
    private static final String NAME = "my-actions";

    public MyActionsInitializer() {
        super(NAME);
    }

    public void updateSettingsMap(Class kitClass, Map settingsMap) {
        MyAction action = ...
        SettingsUtil.updateListSetting(settingsMap,
SettingsNames.CUSTOM_ACTION_LIST,
                new Object[] {action}
        );
    }
}

You need to register and deregister the initializer in your ModuleInstall class
(I assume that you have your own module).
Registration:
        Settings.addInitializer(new SysActions(), Settings.USER_LEVEL);
        Settings.reset();
Deregistration:
        Settings.removeInitializer(NAME);

BTW the generic actions for comment and uncomment are ExtKit.CommentAction and
ExtKit.UncommentAction. They are created in JavaKit.createActions() with "//" as
a comment string. I assume that you can just extend the default behavior and
remember the selection for your own processing.
Please let me know if you would have problems implementing this.

I will try the suggested approach myself.

Btw, I had a chat with Petr Nejedly, he understood that what I am trying to 
achieve. And that is trying to make sense of low level DocumentEvents (find 
the upper and lower bounds for the document change) based on high level ones. 
He said this is not going to scale. So what he suggested is try to write a 
stack that will take in document events for a high level event, then run a 
process that listens to stack changes and process the stack once all document 
events subside. From this stack I can calculate the upper and lower bounds of 
changes in the document. So, if solution looks reasonably good (works as 
expected), we can lower the priority of this bug/close this bug.

Not sure whether I understand your last comment. By high-level document changes
you mean the whole comment-action running over a bunch of lines while the
low-level document changes are changes to the individual lines?
I thought that you will redefine the comment action like this:

public void actionPeformed() {
  if (selection) {
     remember-starting-and-ending-line-indexes-of-selection
  } else { // no selection
     remember-sinle-line-index
  }
  call-original-comment-action
  use-the-preceding-information-to-do-whatever-you-need
}

Anyway, please close the issue when appropriate or let us know to do that. Thanks.

What I meant is that, the solution above for comment/uncomment will work as 
expected. Let's say now we have to address "Refactor" a high-level event 
(Currently I haven't address it, and is not a requirement for now). We will 
have to address it. This means our solution to listen to each and every high 
level that has an impact on the document does not scale. So the solution that 
Petr Nejedly proposed was to address this at the low-level (ie stack each 
insertUpdate, removeUpdate calls to the DocumentListener, then process them).
I don't know if I made sense at all.  

Based on Petr Nejedly's suggestion, I have attempted to write a 
queue in our code, that will take in document events for a high level event, 
then run a thread that listens to queue changes and process the queue once all 
document events subside. From this queue entries I can calculate the upper and 
lower bounds of changes in the document. The solution looks reasonably good, 
so I am lowering the priority of this bug to P4. 

This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss