SlickEdit Community
Archived Beta Discussions => SlickEdit 201x Beta Discussions => SlickEdit 2017 v22 Beta Discussion => Topic started by: rowbearto on September 08, 2017, 05:16:40 PM
-
This issue has been around for as long as I have been using SE.
I work in a Linux NIS/Clearcase environment. Certain directories (example: /vobs) take a very long time to list all the files. For example, if I type "/vobs" into smart open, SE freezes for a very long time while it tries to get a listing of all the files in /vobs. The same thing happens when I do "ls /vobs" at the command line. Even if I want to go to the directory /vobs/dir1/dir2, SE is frozen after /vobs for a long time, hurting productivity, even though I don't need a listing of the files there. My workaround is to usually type a junk character first, like s/vobs/dir1/dir2, then remove the "s".
It would be helpful if SE can enumerate the directory in a background thread or not freeze while waiting for the directory listing.
-
In the future, we would like to add support for recursing some directories (maybe specified by the user) instead of just listing the current directory. This will require threading. We will keep this in mind when we add this.
-
I also have this freezing issue in the BigFind when I type "/vobs" into the "Lookin:" and it tries to enumerate the files in this dir. So this type of threading could be useful here too, or wherever you try to list directories to help the user autocomplete them.
-
Similar freeze issue here when using /vobs (my slow path) when entering paths in DiffZilla.
So I think whenever there is a place where there is a scan of subdirectories to help with auto-completion of paths, if it takes a long time to scan the dir then there is a freeze. If this scanning can be done in the background for path auto-completion it would be real nice!