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
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.
Comment 1Vitezslav Stejskal
2008-11-07 11:36:30 UTC
Comment 2Vitezslav Stejskal
2008-11-07 12:05:48 UTC
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.
Comment 3Vitezslav Stejskal
2010-08-06 11:41:39 UTC
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.
Comment 4Vitezslav Stejskal
2010-08-06 12:21:26 UTC
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.
(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.
Comment 7Vitezslav Stejskal
2010-08-18 09:29:40 UTC
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.
Comment 8Vitezslav Stejskal
2010-08-24 13:04:35 UTC
Thanks for the review. I'm going to integrate this together with issue #189638.
Comment 9Vitezslav Stejskal
2010-08-27 11:20:40 UTC
This has been pushed to jet-main clone together with changes made for issue #189638.
Comment 10Quality Engineering
2010-08-31 03:21:49 UTC