Re: while-no-input

[Richard Stallman <rms@gnu.org>]

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
    the box!


    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?