Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-dev] Q: jface.text.reconciler

Hi all.

Can anybody explain to me some details regarding  jface.text.reconciler

I'm investigating problem with CDT editor performance. 
CDT source editor uses standard jface reconciling mechanism, 
providing only it's own IReconcilingStrategy implementation.

Now incremental reconcile mode is off
It means, in particular, that CDT have to re-parse whole source file
after each change
in editor. Of course, it's not nice.

I have tried to set reconciler.setIsIncrementalReconciler(true) and
analyze dirtyRegion
contents in CReconsilingStrategy.reconcile(D, R), to avoid useless
parsing if possible.

This method is called from

The following problems are met in this function:

1. If dirtyRegion contains text literal(s), computePartitioning() method
returns several regions.
So,  CReconsilingStrategy.reconcile(D, R) is called twice or more with
the same dirtyRegion.
Since I need only dirtyRegion (not region) data for analyze, subsequent
calls are useless. 
I can filter them out, but this solution looks like hack.

Is there a normal way to call ReconsilingStrategy.reconcile() only once
for given dirty region ?
May be Reconciler.setDocumentPartitioning() should be used before, but I
don't know how.

2. If I delete a big fragment of document contents, the following
problem can occur:
      - document updated and became shorter (for example, 200 chars)
      - dirtyRegion has (for example) offset=100 and length=200.
      - method Reconciler.computePartitioning(int, int) fails with
BadLocationException when
        tries to compute partitioning for this situation, since
offset+length > doc size.
      - as a result, subsequent call to IReconsilingStrategy.reconcile()
is not done at all.

Note, there's no any CDT-specific code involved in this process yet, so
may be it's not only my problem.
Can it be fixed anyhow ?

3-rd question is not related exactly to Reconciler.process(), but...
How can I access "deleted" data ? When deletion occurs, DocumentEvent
contains only offset and length.
Call to
returns already modified text.
Is it possible to find somewhere deleted fragment (or document copy
before deletion) by standard means ?

Can anybody help ? Sorry, I am not familiar enougth in JFace details.

Thanks in advance.
With best regards, Oleg Krasilnikov
Software designer, Eclipse team. 
Intel corp.
+7 8312 162 444 ext. 2587 
(Russia, Nizhny Novgorod)

Back to the top