Community
Participate
Working Groups
Build Identifier: 20100917-0705 If an editor with a FileDocumentProvider like Xtext is dirty while replacing the file inside eclipse, the workspace knows the new File (the IFile is synchronized in this case) but the editor should be dirty. The TextFileDocumentProvider uses a FileInfo with i.e. ResourceTextFileBuffer which also compares the last known modification timestamp. Reproducible: Always Steps to Reproduce: 1. Open a Xtext-Editor (It depends on synchronization of the FileDocumentProvider) 2. Change the file and do not save 3. Replace the file with one from local history and deny the question to "save" 4. If the editor becomes active again, the file change is not recognized (No message for replace the content is shown) 5. Try to save (Error message, because the file changed)
Xtext should switch to the TextFileDocumentProvider. Most fixes and new work was only done there.
FileDocumentProvider doesn't appear to be deprecated, though.
(In reply to comment #2) > FileDocumentProvider doesn't appear to be deprecated, though. It can still be used for the old and simple cases (e.g. the class file document provider extends it). Also, when using/extending the textual editors from the SDK you'll get the TextFileDocumentProvider for free.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
