Henry S. Thompson wrote: > OK, so Klaus's guess _appears_ to be backwards. > > To recap: I had gotten rid of the problem by setting both > > ecb-prescan-directories-for-emptyness nil > ecb-vc-enable-support nil > > Klaus said he suspected prescan, so I turned vc-support back on -- > hang comes back! > > So I turned it off again, and enabled the emptyness scan -- no hang. > > So my current belief is that it's the vc support that's the problem, > not the emptyness check. Which is slightly more plausible if only > because vc support is new and emptyness is not, right?
well, are you working with CVS?? If yes, do you use a remote repository (e.g. something like :ext:[EMAIL PROTECTED]:/cvsroot/ecb)?? If yes and you use XEmacs then you have the bad luck, that the VC-package (vc.el et.al.) of XEmacs is fully outdated - compared to the GNU Emacs one really ... bad programmed and not really powerful concering customizing... You can make a test for me - Please do: M-x (ecb-vc-dir-managed-by-CVS "full/directory/name/of/a/dir/managed/by/a/VC") RET and tell me the result and tell me if this call takes a long time? GNU Emacs allows to stay local for remote CVS-repositores and to compute the VC-state in a heuristic approach which is not really 100% correct but is sufficient for most situations and is much faster than sending real CVS-commands like "cvs status" to a remote repository - XEmacs does this - and therefore checking the VC-state of each file in a directory (done by ECB) takes a long long time for a single file and a log long long long time for the whole dir - ECB does this stealthy but here we have that problem wit cygwin-XEmacs i have tried to describe in one of my postings yesterday... Klaus > > ht
