RE: while-no-input

[klaus.berndl]

Stefan Monnier wrote:
>> The only thing programs do to control quitting is to bind
>> inhibit-quit on and off.  That is not relevant to handling
>> with-no-input, so I think 
> 
> Could you substantiate that claim?
> AFAIK inhibit-quit is used to get more-or-less-atomic behavior in
> places where it matters.  while-no-input should very clearly obey
> inhibit-quit since it also causes non-local exits at places where it
> can't be predited (just like quit).
> Don't forget that the code within while-no-input is usually code that
> was not specifically designed for while-no-input (otherwise it would
> already use input-pending-p instead).

Hmm, are you sure about that??
IMHO the code within while-no-input can also be code which would use
input-pending-p already, so my example with performing a VC-state-check
for a set of files which i want to be interruptable by the user at EVERY
timepoint.... with only input-pending-p i can only interrupt directly before
the next VC-state-check, because the call `vc-state' rsp. `vc-recompute-state'
is not interruptable unless by hitting quit... 

But if i could encapsulate processing my set of files in your while-no-input
macro then it could be interrupted at EVERY timepoint, if i have understood
you right, because this would also interrupt the inner state-check-function,
wouldn't it?

So i would do

(while-no-input ....
  (unwind-protect
  ;; checvk the state for the set of files in BODYFORM
    ( ;; cleanup whatever is to clean up
     ))

Have i understodd this right?

> 
> Here is another way to say the ame thing: of all the non-local exits
> we have right now, `quit' is the only one that's asynchronous. 
> `while-no-input' introduces another form of asynchronous signalling
> and is thus much more like `quit' than like `throw'.