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:||Aggregate token hierarchy listener|
|Product:||editor||Reporter:||Miloslav Metelka <mmetelka>|
|Component:||Lexer||Assignee:||Miloslav Metelka <mmetelka>|
|Issue Type:||TASK||Exception Reporter:|
Description Miloslav Metelka 2007-11-26 16:09:59 UTC
Besides individual token hierarchy events it would be useful to provide aggregated changes too. It would be useful for incremental parser-like tools that need to fix their structures based on lexical changes but that do not want to do that after every document modification. The only requested chunking of the aggregation so far (and imho the most reasonable) were the atomic document edits (i.e. NbDocument.runAtomic() transactions) which cover e.g. code reformatting and the common document edits. Technically the lexer would provide TokenHierarchy.add/removeAggregatedTokenHierarchyListener(TokenHierarchyListener) The fired event would contain a union of all the relexed regions from the individual changes. If two regions would be far enough from each other so that there would be some unchanged tokens then these unchanged tokens would be reported as removed (by TokenChange.removedTokenSequence()) and re-added (they would be present in TokenChange.currentTokenSequence()). Although in practice the changes that would not be adjacent are rare the tools could get a fine-grained info by checking Token.isRemoved() (result of an issue 122786) on the tokens returned by TC.removedTS() to find out whether a particular token was really removed or if it was amidst of two non-adjacent modifications. In practice most of the clients can possibly use aggregated token hierarchy listening rather than regular grained listening. For example syntax higlighting will not be rendered until the document is read-lockable and it only needs to know the affected region of the token modifications so it would be fine to use the aggregated listening. There could be a boolean parameter collectRemovedTokens added to TH.addAggregatedTHL() to possibly omit collecting of the removed tokens if there would be no client requesting that (e.g. the syntax highlighting client is not interested in that information).