Community
Participate
Working Groups
M2 Change is to rename a field in the editor from 'x' to 'x1': 1. On the change a delta 'content | fine grained, field x removed, field x1 added' is sent. 2. On save, a delta 'content | fine grained, no affected children' is posted. The second delta is unnecessary, it contains no information. The information that a save was done is interesting but probably can not be detected from the current delta ('content | fine grained, no affected children')
This delta indicates that a change to the content of the compilation unit was made (it could be a change in a comment) but no structural difference exist. So I think this delta contains some information and should be kept as is.
In step 2. the file is only saved: No change on the file not even a change in the comment)
OK, but the Java model doesn't keep the previous content of the file. It only keeps the structure of the cu. So it cannot know that absolutely no change was made.
I don't understand that. The cu is in working copy mode and the delta listener listens on document changes. A IResource change can be ignored in this case, no? The question of course it, what happens if somebody external makes a change on a resource while the file is in working copy mode. But I think such changes on the resource are ignored and overridden when the working copy is commited. I think it's important to not send unnecessary deltas as it leads to unnecessary refreshes in viewers and refreshes in caches ect.
So are you saying that changes (including addition and deletion) should not be reported through a Java delta if the primary cu is in working copy mode?
Problem is that if this delta is discarded, then type hierarchies will not get notified of possible need to refresh (hierarchies are not listening to working copy deltas currently for performance reason). So either we keep a delta (with special flag?) or type hierarchies will get notified of intermediate deltas, and will refresh when it makes sense (performance), could be on save action only. The scenario which causes trouble in reconciler is the addition of an unterminated type comment '/*' which immediately treats a significant portion of the unit as discarded.
I would prefer the 'special flag' solution. In other words a delta simply reporting that a document has been saved (what only would be information, not a real delta)
Committing a primary working copy should only force a reconcile, if it is already reconciled, this is a no-op: no delta. As well we will filter them out in DeltaProcessor. Type hierarchy should store fine-grained deltas and traverse the working copy on save to check if supertypes have changed. We might want to use reconcile on save and use the resolution to find out what has changed in the working copy. Known problem: move of a local type inside a method can change its hierarchy.
Fixed commit operation and DeltaProcessor. Added regression test WorkingCopyOwnerTests.testDeltaCommitPrimaryWorkingCopy1() Problem with type hierarchy update is captured in bug 43294.
Verified.
