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.
| Summary: | NavigationFilter in Caret API | ||
|---|---|---|---|
| Product: | editor | Reporter: | Svata Dedic <sdedic> |
| Component: | -- Other -- | Assignee: | apireviews <apireviews> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | sdedic |
| Priority: | P2 | Keywords: | API, API_REVIEW_FAST |
| Version: | 8.2 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Bug Depends on: | 257893 | ||
| Bug Blocks: | |||
| Attachments: |
Proposed changes
Proposed changes, MM01-03 implemented |
||
Svata, thanks for the navigation filtering extensions. MM01) CaretMoveContext.getMoveOrigin() could IMHO be removed since the writers of the corresponding hanlder may pass the information by themselves if they would need it and the filter writers have it in the NavigationFilterBypass. MM02) There are some special internal move transactions e.g. for insert-at-offset-zero which corrects caret related positions located at zero offsets which would not move due to swing text package "feature" of not moving zero-offset positions upon insert at zero offset. IMHO this treatment should be excluded from any filter-related behavior. There's a CaretTransaction.RemoveType.DOCUMENT_INSERT_ZERO_OFFSET for it so it's likely that it will not touch any filtering code but please double check. MM03) Although the physical storage of the filters is in component client properties (like JTC.getNavigationFilter() is as well) IMHO we should rather have static EditorCaret.setNavigationFilter(JTextComponent, MoveCaretsOrigin, NavigationFilter) since at component's initialization when the filters will be set as well there could be still an original non-EditorCaret instance set which would in fact prevent us from setting of the filters. Thanks. Created attachment 159425 [details]
Proposed changes, MM01-03 implemented
MM02: I've checked the implementation, and DOCUMENT_INSERT_ZERO_OFFSET bypasses the public entry points which work with caret filters. But adding an explicit instruction seems reasonable.
If no further issue or feedback comes, I'll integrate the change tomorrow. Thanks all! Integrated into 'main-silver', will be available in build *201604280002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/d3c96bbc2e2b User: Svata Dedic <sdedic@netbeans.org> Log: #258824: NavigationFilter support implemented |
Created attachment 159266 [details] Proposed changes For a possible console-like feature, I need to filter editor caret movements (so I can implement usable navigation in the editable area vs. scrollback). Until introduction of multi-caret and Caret API I was able to solve (somehow) the requirements by using Swing NavigationFilter. After Caret API was introduced, I've adapted the filter implementation. This issue attempts to introduce NavigationFilter support including extensions for Caret API - aware filters. There are also other additions (see MoveCaretsOrigin class) to Caret API, which could be solved in a hacky way (e.g. client properties) but since now a dedicated Caret API exists ;) there's a place to publish such additions. Please review & comment.