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, setUserMappublic 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)
AsyncFileListenerProgressManager.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 AsyncFileListenerpublic void installVFSListener(Disposable parentDisposable)