[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 29 Nov 2004 15:30:51 +0100
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,
So i would do
;; 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'.
- RE: while-no-input,