>>> OK, so Klaus's guess _appears_ to be backwards.
>>> . . .
>>> 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??
> 
> Yes.
>> If yes, do you use a remote repository
>> (e.g. something like :ext:[EMAIL PROTECTED]:/cvsroot/ecb)??
> 
> Yes.
> 
>> 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... 
> 
> Sigh :-(
> 
>> 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?
> 
> CVS, and no, but not for any interesting reason:
> 
>  You check the cvs root for @.*:, but although my root is remote, it
>  doesn't match because, per your comment in line, it has no username,
>  i.e. it looks like mhost.mydom:/home/cvsroot
> 
> So I patched the pattern and still no pause -- ah -- on cygwin you

how do you have patched the pattern?? maybe i should patch the pattern
in ECB too!!

> need
>  (setq ecb-ping-options '("-s" "1"))
> to avoid an error.
> 
> OK, so finally, a modest pause followed by
> 
> 'CVS

OK, then ECB has checked if the remote host is accesible...

>> 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...
> 
> Understood.  The above errors cancelled themselves out, ecb thinks I'm
> using CVS (which I am), so it goes into this long uninterruptable
> sequence.
> 
> So the _principled_ solution is to find a way to get VC improved for
> XEmacs and/or to fix the cygwin interruptability pblm.

The former one is in progress - at least AFAIK - Ville Skyttä is working
on synching XEmacs VC with GNU Emacs VC - but i would not hold my breath
until it is ready for release ;-))

The latter one: Hmm, maybe i write a report to XEmacs-team - but somehow this
problem is hard to catch and to describe...... 

Klaus

Reply via email to