Re: last try (was: while-no-input)

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

> >     > Please don't ask me to spend more time on this.
> >     > I have lots of other work to do, and I've made the decision.
> >     But this decision is just wrong.
> > I think it is right, so what can I say?
> 
> How about rebuffing the arguments you excised ?
> You're not really attempting to justify your position.

Well, I can fully understand why Richard thinks that using signal is
the wrong approach.  That is the obvious conclusion one would make if
only thinking about the "formal appearence" of the proposal, without
thinking about the substance of the problem that it tries to solve.

IMHO, Stefan's patch isn't ugly at all; actually, it is a pretty damn
clever solution to a tricky problem!

I can understand Stefan's frustration that the idea is rejected merely
on the reason of "ugliness".


However, the bad thing about this whole argument is that, as Stefan
has clearly pointed out (without Richard actually arguing against
that), using throw/catch _DOES_NOT_WORK_ for the specific problem that
while-no-input is supposed to solve.

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!

So although Richard may be right that signal is _formally_ the
wrong vehicle for while-no-input, it is the only vehicle which
will work without modifying the code we want to encapsulate.

So Richard, whether you want it or not, you need to think some more
about this issue to:

- either show us (in detail) how throw/catch can be used to achieve
the described goals without having to modify ange-ftp and tramp (and
every other package that may install file name handlers),

- or admit that Stefan's signal quit approach (however ugly you think
it is) is a valid approach which actually will do the job properly
with the least amount of work -- and it's already done!


-- 
Kim F. Storm <address@hidden> http://www.cua.dk