[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 29 Nov 2004 01:11:08 -0500
Here's where the discussion ended up:
The problem is that we need while-no-input to be able to encapsulate
_UNMODIFIED_ code (such as ange-ftp and tramp) so that user input
transparently "interrupts" (or quits) that code.
Obviously, the code we need to encapsulate must already have been
written to intercept the "quit" signal to be able to properly clean-up
network connections etc. due to a keyboard-quit.
Therefore, the most obvious solution -- once you see it -- to
implement while-no-input is to use the quit signal as an indication
of pending user input. That way, the existing code to handle
the quit signal will make while-no-input work transparently out of
In contrast, using throw/catch instead of Stefan's `annotated' quit
signal _DOES_NOT_WORK_ since the code we really want to encapsulate,
such as ange-ftp and tramp, is not written to expect a non-local exit
due to non-quit events!
I doubt that argument. Usually the way to arrange to clean something
up is with unwind-protect, and that will handle any nonlocal exit.
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
there is really no advantage in using signals.
Can you find any real code where using a quit signal would work better
than using throw?