Created attachment 119982 [details]
If one saves document and immediately copies new content via streams, document still contains the old content.
Unit test attached, I hope it is correct :)
Product Version: NetBeans IDE Dev (Build 20120528-3c75442ef118)
Updates: Updates available
Java: 1.6.0_32; Java HotSpot(TM) 64-Bit Server VM 20.7-b02
System: Linux version 3.4.0-030400-generic running on amd64; UTF-8; cs_CZ (nb
*** This bug has been marked as a duplicate of bug 207060 ***
Have to reopen, it does not seem to be fixed - at least the test still fails for me. Can you please verify, Jardo?
Product Version: NetBeans IDE 7.3 Beta 2 (Build 201211052012)
Updates: NetBeans IDE is updated to version NetBeans 7.3 Beta 2
Java: 1.6.0_35; Java HotSpot(TM) 64-Bit Server VM 20.10-b01
Runtime: Java(TM) SE Runtime Environment 1.6.0_35-b10
System: Linux version 3.2.0-32-generic running on amd64; UTF-8; cs_CZ (nb)
Thanks for the test. The FileChange event is delivered as soon as the stream closed and is synchronously passed to CloneableEditorSupport as PROP_TIME change. The support detects it needs to reload. Then it however starts to switch between EDT and outside of EDT, so it is not easy to find out the document has already been refreshed.
Passing to openide.text...
Btw getting the content of editor in the test should definitely be done in Document.render().
The reload is done in AWT since the caret position needs to be restored after the reload which has to occur in AWT.
In the future we could think about doing the reload by applying diffs between current editor's content and the loaded content which could possibly eliminate need for a caret update but it is rather a thin ice.
So I close this as wontfix. I guess that getting the content in invokeLater() would probably work (since the reload task would already be in the AWT queue) if it would work for you as a workaround for your usecase.
BTW workaround for this issue (at least for me) was to add a sleep() for 1 second.