This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
There is no easy way how modules could influence keyboard events processing in the editor. The old editor.lib provides several proprietary hooks that can be used in certain specific situation, but they are not suitable for general use. Their main drawback is that they are provided in the form of protected methods on DefaultKeyTypedAction and a few other actions. This means that modules have to subclass these actions and place them in the editor's keymap, which in general is only possible for modules that own particular editor implementations (eg those that implement EditorKit for a given language). The goal in this task is to create Typing Hooks SPI, which would let modules implement keyevents interceptors and register them in MimeLookup. The new SPI will have to coexist with the existing hooks in editor actions in order to allow gradual transition. Obviously it will have to support all (reasonable) usecase that are supported by the action hooks.
Created attachment 73459 [details] Typing Hooks SPI javadoc (version 1)
I have a first version of the SPI and its javadoc is attached above. The package to look at is o.n.spi.editor.typinghooks. I also have an implementation behind this SPI, although it does not fully support everything described in the javadoc. There is still a few API things that I'd like to sort out prior asking for an official review. I'd like to use TypedTextInterceptor for handling new lines creation (ie. InsertBreakAction). And I'd like to add TextDeletedInterceptor or something similarly named as a replacement for the hooks in DeleteCharAction. Apart from that the main concept is done and I'll be thankful for any feedback.
Created attachment 101244 [details] Typing Hooks SPI javadoc (version 2) This is the javadoc of the complete SPI with all the interceptors that were planned and completed javadoc, arch and apichanges documents.
I'd like to ask for the review of Typing Hooks SPI. I'm not sure if the fast track review is suitable for this addition, but if it is not please change the keyword and I'll set up a meeting for the full review. Please look at the attached javadoc (Typing Hooks SPI javadoc, version 2). The SPI itself is in org.netbeans.spi.editor.typinghooks package, which contains the overall description as well as the descriptions of all the interceptors. Unfortunately, I don't seem to be able to generate a reasonable patch that would show just the SPI related changes. The changes are spread across many changesets in a private hg clone, which I have been semi-regularly updating from jet-main. I can zip-up the sources of editor.lib2 and editor.lib and attach them here with pointers to the relevant classes if somebody is interested. Thanks!
(In reply to comment #4) > Please look at the attached javadoc Not an expert in this area but it looks good to me. > I don't seem to be able to generate a reasonable patch that > would show just the SPI related changes. The changes are spread across many > changesets in a private hg clone, which I have been semi-regularly updating > from jet-main. Just do another synch from jet-main if you have made any regular changes in the branch since the last synch. Then run hg diff between the parent of the merge changeset that was from jet-main, and the merge changeset itself. This will be the cumulative patch.
It seems to me to be good and straightforward to use. I have several questions: MM01) Embedded sections: will embedded sections' hooks be triggered in any way as well? Possibly we could allow that if explicitly registered for a composed mimepath. MM02) Is the SPI supposed to treat all the tweaks including automatic brace competion; string-literal-at-eol splitting etc.? I hope so since even though there may still be additional SPIs for these things by using this SPI we would at least standardize ordering of those hooks.
Re. MM01 - I'm not sure if I understand, but since the interceptors are looked up from MimeLookup all the rules that apply for MimeLookup will apply to interceptors as well. That is, for example, if there is a javascript section embedded in an html (ie. MimePath == "text/html/text/javascript") all interceptors registered for "text/html/text/javascript", "text/javascript", "" will be used. Re MM02 - Yes, I think so. The SPI should be able to accommodate any functionality that is now implemented by subclassing editor actions such as DefaultKeyTypedAction, etc. However, I admit that I haven't yet rewritten any of those features (eg. from java editor) and so we may find some limitations.
Thanks for the review. I'm going to integrate this together with issue #189638.
This has been pushed to jet-main clone together with changes made for issue #189638.
Integrated into 'main-golden', will be available in build *201008310001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/6285fb15db94 User: Vita Stejskal <vstejskal@netbeans.org> Log: #152655: javadoc