public class DirtyScopeHolder extends UserDataHolderBase implements AsyncFileListener
AsyncFileListener.ChangeApplier
Modifier and Type | Method and Description |
---|---|
boolean |
contains(VirtualFile file) |
java.util.Set<Module> |
getAllDirtyModules() |
GlobalSearchScope |
getDirtyScope() |
void |
installVFSListener(Disposable parentDisposable) |
AsyncFileListener.ChangeApplier |
prepareChange(java.util.List<? extends VFileEvent> events)
Called (possibly on a background thread) when a batch of VFS events is ready to be fired.
|
void |
upToDateChecked(boolean isUpToDate) |
changeUserMap, clearUserData, clone, copyCopyableDataTo, copyUserDataTo, getCopyableUserData, getUserData, getUserDataString, getUserMap, isUserDataEmpty, putCopyableUserData, putUserData, putUserDataIfAbsent, replace, setUserMap
public void upToDateChecked(boolean isUpToDate)
public GlobalSearchScope getDirtyScope()
public java.util.Set<Module> getAllDirtyModules()
public boolean contains(VirtualFile file)
public AsyncFileListener.ChangeApplier prepareChange(java.util.List<? extends VFileEvent> events)
AsyncFileListener
ProgressManager.checkCanceled()
often enough.
Note that this listener can only observe the state of the system before VFS events, and so
it can't work with anything that would be after them, e.g. there will be no file in
VFileCreateEvent
, FileIndexFacade
won't know anything about the updated state after VFS change, and so on.
Note that the events posted passed might differ from the ones passed into BulkFileListener
.
In particular, there may occasionally be several events about the same file (e.g deletion and then creation, or creation and
then deletion of the file's parent). Hence the order of events is significant. Implementations should be prepared to such situations.
prepareChange
in interface AsyncFileListener
public void installVFSListener(Disposable parentDisposable)