[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: vc-state always calls heuristic function

From: klaus.berndl
Subject: RE: vc-state always calls heuristic function
Date: Wed, 24 Nov 2004 15:44:27 +0100

Stefan Monnier wrote:
>> and between each pass of the loop it is interruptable..well, but of
>> course there remains the problem - how to interrupt if one pass
>> takes long 
>> time...
> Google for `while-no-input'.

Done - after reading the whole thread i can say: I agree at 100% with you and 
Such a macro would be very important especially for a program like Emacs which
has still not thread-feature like Java, C++ et. al. IMHO this is one of the
most important any annoying lacks of emacs-lisp and for programmers...
And i agree with Kim that especially people working with remote-paths and
packages which makes this completely transparent (like tramp, ange-ftp and efs)
would profite a lot from such a macro like while-no-input - 

The current discussion how to enable tools like ECB to display some state-value
for files (as the VC-state-values) where the computation could be expensive
is IMHO a good example to demonstrate the need of such feature - so we have no
threads avaliable in emacs-lisp to perform such expensive tasks in the 
without blocking the user of Emacs but we could at least offer the users of
such tools a way how to easily (hitting C-g is not acceptable) interrupt also
"atomic" calls as call of call-process etc...

Well, Stefan - this thread was discussed in 2002 - what is current state of
this while-no-input???

>> Hmm, now i'm confused... ECB needs a function how to get the
>> VC-state. Well, the user can customize which function ECB should
>> use.  But if he should 
>> not use `vc-recompute-state' how he should get fresh-but-slow state??
> Oh, you're right I got confused: vc-cvs-heuristic-state doesn't pay
> attention to vc-cvs-stay-local.  Hmmm....
> I guess VC could/should provide a function like vc-recompute-state or
> vc-check-for-updates.  Currently this operation is only provided as
> part of vc-next-action, but it might be nice to decouple the two.

Yes, see my discussion with Andre about this...


>         Stefan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]