Sorry for increased the priority but it's really necessary for us to be able to implement delete word functionality. Any resolution like override of CslEditorKit actions or another interceptor is OK for us. Thanks.

Created attachment 127236 [details]
Patch for DeleteWord API

MK1: I introduced new API org.netbeans.modules.csl.api.DeleteWordHandler - DeleteWordHandler with Typing Hooks is the newer alternative for KeystrokeHandler. 

MK2: Example for use is in javascript2.editor/src/org/netbeans/modules/javascript2/editor/JsDeleteWordHandler.java There isn't used KeystrokeHandler

MK3: I rewrite all csl typing actions to default csl typing hooks. These typing hooks works only when language register KeystrokeHandler and are introduced just for backcompatibility. I tested it on html.editor, php.editor, web.core.syntax(jsp)

MK4: There is a test infrastracture in csl.api/test/unit/src/org/netbeans/modules/csl/editor/TypingCompletion.java .A few examples are in html.editor, php.editor, web.core.syntax. Clients of Csl are welcomed to use it. 

MK5: Html typing actions and Jsp typing actions are deleted. For Jsp Java typing hooks are working just well. And since Jsp had dependency on Java typing actions, I could finally deleted Java typing actions and Java BraceCompletion.

OB01: Please, try to run org.netbeans.modules.php.editor.indent.PHPBracketCompleter.java test with these changes applied. 
Probably you should run tests of all clients ;)

OB02: And I'm not sure if such a big change should be implemented after Beta2...isn't that too big?

Thanks.

Ad OB01: 8 tests failed, please look at it. Thanks.


OB03: DeleteWordHandler.getNextWordOffset...returns int, so there shouldn't be @CheckForNull annotation imho

OB04: same for int getPreviousWordOffset(Document doc, int caretOffset);, probably no @CheckForNull

Thanks for implementation in the JS, JSP. I didn't try it out them in practice, I'll take a look on that tomorrow.

API:
MF01 - Improve DeleteWordHandler class javadoc olease. At least registration HowTo would be welcomed there.
MF02 - Deprecated KeystrokeHandler but not usages in the API - like UiUtils#getBracketCompletion()? So basically does it mean that the API will have another review in the future?

Clients:
MF03 - Shouldn't you update spec. version dependencies of the JSP, HTML and PHP on the CSL? It looks to me that one can update i.e. html module but the CSL is not updated together so he will lose functionality?
MF04 - Clean-up unused imports and trailing spaces of all classes please (including API).
MF05 - Has the JsDeleteWordPositionHandler in the JS2 layer any purpose?

OB01: +1

OB05: Some files are changed just because of added/removed whitespaces (e.g. Language). Don't include em in the patch please :) Thanks a lot.

Thanks for doing this Mita!

MJ01: I would suggest to create only one method with a boolean reverse
parameter instead of having two methods. Don't see much benefits from it (most
of the clients will do exactly the same as you did in JsDeleteWordHandler -
create private method with boolean parameter to remove duplicity). Or is there
any particular reason for that?

MJ02: Would it be possible to move the DeleteWordHandler to Editor Library 2
which contains all other interceptors? Not sure if it's possible, but seems to
me a little bit confusing that we have two similar concepts (intercepting key
events) splitted in two different modules

MJ03: Minority problem - could you please clean up the patch a little bit?
There are some classes (e.g. JspKit) where you are adding new import
statements, but they are never used.

One more note to MF05: If it does have any purpose, there is a wrong link to
the DeleteWordPositionHandler which is not in csl.api (I guess it just wasn't
refactored correctly)

@MK5 Removing JSP, Java Actions in Bug #219834

I am rewriting whole API. I am implementing DeleteWordInterceptor to editor.lib2. I am adding a replaced text variable for TypedTextIntereptor, it will help to pass php tests.

Since it looks like the new API will not be available in the NB7.3 I used to old way using KeystrokeHandler (web-main #0fc25bfe7604) in the javascript2 for now.

BTW, this API still really make sense to me since our keystrokeHanlder has implemented only one method needed in cases of the word offsets.

So feel free to set TM => Next. Thanks...

Martin, thank you. I am sorry, I had a lot of work recently and these changes are quite big.

I prepared new API. I added new interceptor for camel case action like remove next/previous word, select next/previous word and insert point to next/previous word.

I moved java and csl action to editor.actions and implement csl and java implementation of camel case interceptor.

The client of csl has now 3 options:
1, implement keystrokehandler
2, implement keystrokehandler only with getNextWordOffset method and implement typing hooks without camelcase
3, implement all typing hooks (also with camelcase) and sets typing hook to null.

I checked php editor test and all passed after this change. Php uses now 2nd option.

Created attachment 133390 [details]
CamelCase API

Sorry, I'm not able to review whole diff since it's pretty big change in areas I don't know well. Anyway I tried at least implement CamelCaseInterceptor for JavaScript which worked well to me and I was able to remove deprecated KeystrokeHandler then.

MF06: Since the KeystrokeHandler is divided into 3-4 interceptors, it would probably deserve better JavaDoc how to switch from deprecated interface.

Martin, thank you for a test and comment.

Integrated in http://hg.netbeans.org/jet-main/rev/90e449c21ae3

Integrated into 'main-golden', will be available in build *201304172301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/90e449c21ae3
User: Milutin Kristofic <mkristofic@netbeans.org>
Log: #217163 - There is no way to define deleted word interceptor/behavior