Community
Participate
Working Groups
In 3.0 final, a document partitioner is not called until after other document events are processed. In 2.0 and in all (?) milestones preceding 3.0, partitioner was called _before_. This breaks listeners who expected the partitioner to have completed before they were called, and thereby breaks my editor plugin. The VisibleDocumentListener that does the reconciliation, running the partitioner, is added in TextViewer setVisibleDocument(). Currently my editor's DocumentListener is added in the TextEditor subclass's doSetInput() method, which is about as late as I can leave it. Prior to 3.0, this always got the listeners in the correct sequence. (Note that it is not acceptable to wait for a partitionchanged event instead of documentchanged, because not all changes result in partition changes.) To fix this I need a reliable way to set a listener that will not run until the partitioner runs.
After some additional poking around, it appears that a better place to add my document listener would be in createPartControl(). AbstractTextEditor createPartControl is where the sourceviewer gets initialized, and indirectly the VisibleDocumentListener gets added. Does this seem like a reasonable fix? (It may even be 2.0-compatible.)
Only having it there won't do the trick since editors can be reused.
Which is exactly why the code was in doSetInput() in the first place. But since it no longer works to put it there, any suggestions? I see that the document listener is only added when the sourceviewer is initialized and removed when the text widget is disposed. That implies (if this works correctly) that a new sourceviewer/text widget is created when the editor is re-used. Where does this happen?
Fixed in HEAD
Ignore comment 4 (wrong bug report)
This seems a monkey-see, monkey-do situation. I see your PresentationReconciler and how it sets up an ITextInputListener to listen for document changes and an IDocumentListener to listen for changes to documents. I can do that. One slightly annoying thing is that setDocument is called during createPartControl, so that it is not possible to set a listener to catch the initial documentChanged. I can work around this simply by getting the document after super.createPartControl returns and calling documentChanged directly, but it occurs to me this is yet another fragile hack depending on internal behavior which is not API and might change in any release. It would be better if you realized that having the ability to detect document changes _after_ the partitioner has a chance to run is something that editors will commonly want to do, and provided API that guarantees it. (Or, if you have already done so, please let me know what it is.)
Unfortunately the method which would fit your needs (initializeSourceViewer) for adding the listener is private and not protected. I close this one as a dup of a more general bug 71081. *** This bug has been marked as a duplicate of 71081 ***
