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.

Bug 258824 - NavigationFilter in Caret API
Summary: NavigationFilter in Caret API
Status: NEW
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 8.2
Hardware: PC Linux
: P2 normal (vote)
Assignee: apireviews
Depends on: 257893
  Show dependency tree
Reported: 2016-04-14 11:28 UTC by Svata Dedic
Modified: 2016-04-28 02:03 UTC (History)
1 user (show)

See Also:
Exception Reporter:

Proposed changes (66.04 KB, patch)
2016-04-14 11:28 UTC, Svata Dedic
Details | Diff
Proposed changes, MM01-03 implemented (67.37 KB, patch)
2016-04-25 10:58 UTC, Svata Dedic
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Svata Dedic 2016-04-14 11:28:16 UTC
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.
Comment 1 Miloslav Metelka 2016-04-20 13:16:09 UTC
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.

Comment 2 Svata Dedic 2016-04-25 10:58:39 UTC
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.
Comment 3 Svata Dedic 2016-04-26 14:28:29 UTC
If no further issue or feedback comes, I'll integrate the change tomorrow. Thanks all!
Comment 4 Quality Engineering 2016-04-28 02:03:12 UTC
Integrated into 'main-silver', will be available in build *201604280002* on (upload may still be in progress)

User: Svata Dedic <>
Log: #258824: NavigationFilter support implemented