while-no-input

while-no-input

[Stefan Monnier]

Sometimes I'd like to be able to run something "while there's nothing
else to do".  For example, right now icomplete does not work when
completing file names because getting the list of completions can take
an exceedingly long time.  But if it could say "try to build the list
but abort as soon as the user hits a key", then we could use it
there just fine.

So I have a little patch that does just that.  What it does:

1 - add a quit-on-input variable that causes a quit signal to be sent
    as soon as some user input comes in (and the variable is non-nil).

2 - change QUIT to pass the value of `quit-flag' as part of the quit
    signal so we can tell the difference between a real `quit' and
    a `quit-on-input'.

3 - add a `while-no-input' macro that uses the above facilities to run
    its body and exit as soon as user-input is detected.


	Stefan


Index: keyboard.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/keyboard.c,v
retrieving revision 1.708
diff -u -u -b -r1.708 keyboard.c
--- keyboard.c	27 Sep 2002 17:03:46 -0000	1.708
+++ keyboard.c	1 Oct 2002 21:15:14 -0000
@@ -3374,6 +3402,9 @@
 }
 #endif
 
+
+Lisp_Object Vquit_on_input;
+
 /* Store an event obtained at interrupt level into kbd_buffer, fifo */
 
 void
@@ -3501,6 +3538,14 @@
       ASET (kbd_buffer_gcpro, idx + 1, event->arg);
       ++kbd_store_ptr;
     }
+  
+  /* If we're in a section that requested to be interrupted as soon
+     as input comes, then set quit-flag to cause an interrupt.  */
+  if (!NILP (Vquit_on_input)
+      && event->kind != FOCUS_IN_EVENT
+      && event->kind != HELP_EVENT
+      && event->kind != DEICONIFY_EVENT)
+    Vquit_flag = Vquit_on_input;
 }
 
 
@@ -11038,6 +11029,12 @@
 	       doc: /* *How long to display an echo-area message when the minibuffer is active.
 If the value is not a number, such messages don't time out.  */);
   Vminibuffer_message_timeout = make_number (2);
+
+  DEFVAR_LISP ("quit-on-input", &Vquit_on_input,
+	       doc: /* If non-nil, any input will cause a `quit' signal to be thrown.
+The value of that variable is passed to `quit-flag' and is later carried
+by the `quit' signal.  */);
+  Vquit_on_input = Qnil;
 }
 
 void
Index: lisp.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/lisp.h,v
retrieving revision 1.440
diff -u -r1.440 lisp.h
--- lisp.h	11 Sep 2002 01:59:33 -0000	1.440
+++ lisp.h	1 Oct 2002 21:17:54 -0000
@@ -1759,8 +1760,9 @@
   do {							\
     if (!NILP (Vquit_flag) && NILP (Vinhibit_quit))	\
       {							\
+	Lisp_Object flag = Vquit_flag;			\
 	Vquit_flag = Qnil;				\
-	Fsignal (Qquit, Qnil);				\
+	Fsignal (Qquit, flag);				\
       }							\
   } while (0)
 
Index: subr.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/subr.el,v
retrieving revision 1.326
diff -u -r1.326 subr.el
--- subr.el	29 Sep 2002 18:37:43 -0000	1.326
+++ subr.el	1 Oct 2002 21:18:28 -0000
@@ -1606,11 +1622,25 @@
 
 (defmacro with-local-quit (&rest body)
   "Execute BODY with `inhibit-quit' temporarily bound to nil."
+  (declare (debug t) (indent 0))
   `(condition-case nil
        (let ((inhibit-quit nil))
 	 ,@body)
      (quit (setq quit-flag t))))
 
+(defmacro while-no-input (&rest body)
+  "Execute BODY as long as there's no pending input."
+  (declare (debug t) (indent 0))
+  (let ((quit-sym (make-symbol "input")))
+    `(with-local-quit
+       (condition-case err
+	   (let ((quit-on-input ',quit-sym))
+	     (when (sit-for 0 0 t)
+	       ,@body))
+	 ;; Check it is indeed a quit-on-input.  If not, rethrow the signal.
+	 (quit (unless (eq (cdr err) ',quit-sym)
+		 (signal (car err) (cdr err))))))))
+
 (defmacro combine-after-change-calls (&rest body)
   "Execute BODY, but don't call the after-change functions till the end.
 If BODY makes changes in the buffer, they are recorded

Re: while-no-input

[Richard Stallman]

It is a general principle that to avoid using abnormal
condition handling for programmed control flow.
I think it is very unclean to treat ordinary input
like a quit and then distinguish them later.
So I don't think we should add this mechanism.

It is easy enough to do the job using input-pending-p.
You can use

  (catch 'input
    (...
      (if (input-pending-p) (throw 'input nil))
      ...))

if you want to avoid testing input-pending-p at various
levels in the code.

Re: while-no-input

[Stefan Monnier]

> It is a general principle that to avoid using abnormal
> condition handling for programmed control flow.
> I think it is very unclean to treat ordinary input
> like a quit and then distinguish them later.
> So I don't think we should add this mechanism.
> 
> It is easy enough to do the job using input-pending-p.
> You can use
> 
>   (catch 'input
>     (...
>       (if (input-pending-p) (throw 'input nil))
>       ...))
> 
> if you want to avoid testing input-pending-p at various
> levels in the code.

That is not very useful if inside this body you use library
functions that take a long time to complete, such as file-operations
that dispatch to ange-ftp: you'd have to sprinkle (if (input-pending-p)
(throw 'input nil)) all over the ange-ftp code, just to help some
unrelated package like icomplete.


	Stefan

Re: while-no-input

[Richard Stallman]

    That is not very useful if inside this body you use library
    functions that take a long time to complete, such as file-operations
    that dispatch to ange-ftp:

It doesn't seem like a terribly important case to worry about.

Re: while-no-input

[Stefan Monnier]

>     That is not very useful if inside this body you use library
>     functions that take a long time to complete, such as file-operations
>     that dispatch to ange-ftp:
> 
> It doesn't seem like a terribly important case to worry about.

But that's the case that I'm bumping up against.
And the solution is pretty simple and localized as I have shown.


	Stefan

Re: while-no-input

[Stefan Monnier]

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> 
> > >     That is not very useful if inside this body you use library
> > >     functions that take a long time to complete, such as file-operations
> > >     that dispatch to ange-ftp:
> > > 
> > > It doesn't seem like a terribly important case to worry about.
> > 
> > But that's the case that I'm bumping up against.
> > And the solution is pretty simple and localized as I have shown.
> 
> I don't object to your while-no-input code (I can see it would be useful).
> 
> However, I would really like "find-file-all-completions" to be
> interruptable by keyboard input!
> 
> E.g. in ido-find-file, if I know I'm going to write x/y/z, there's
> really no reason for me to wait for emacs to build the completion
> lists for x and y.  But currently, I have to accept the delay.

That's the whole point of my patch (after all ido.el does pretty much the
same as icomplete from this particular viewpoint).


	Stefan

Re: while-no-input

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> >     That is not very useful if inside this body you use library
> >     functions that take a long time to complete, such as file-operations
> >     that dispatch to ange-ftp:
> > 
> > It doesn't seem like a terribly important case to worry about.
> 
> But that's the case that I'm bumping up against.
> And the solution is pretty simple and localized as I have shown.

I don't object to your while-no-input code (I can see it would be useful).

However, I would really like "find-file-all-completions" to be
interruptable by keyboard input!

E.g. in ido-find-file, if I know I'm going to write x/y/z, there's
really no reason for me to wait for emacs to build the completion
lists for x and y.  But currently, I have to accept the delay.

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

Re: while-no-input

[Richard Stallman]

    But that's the case that I'm bumping up against.
    And the solution is pretty simple and localized as I have shown.

The change is very ugly; too much to be justified by the intended
goal.

However, it would cleaner if instead of generating a quit signal it
did a throw to a specified tag.

Re: while-no-input

[Stefan Monnier]

>     But that's the case that I'm bumping up against.
>     And the solution is pretty simple and localized as I have shown.
> The change is very ugly; too much to be justified by the intended goal.

Could you explain what part you find ugly ?

> However, it would cleaner if instead of generating a quit signal it
> did a throw to a specified tag.

The reason I didn't do that is that it didn't seem necessary
and that I didn't want the QUIT macro to grow, but I could introduce
a new function `quit' that the QUIT macro could call and which would
either call `Fsignal (Qquit, Qnil)' ot `Fthrow (...)'.


	Stefan

Re: while-no-input

[Richard Stallman]

    The reason I didn't do that is that it didn't seem necessary
    and that I didn't want the QUIT macro to grow, but I could introduce
    a new function `quit' that the QUIT macro could call and which would
    either call `Fsignal (Qquit, Qnil)' ot `Fthrow (...)'.

That would be ok.

Re: while-no-input

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     That is not very useful if inside this body you use library
>     functions that take a long time to complete, such as file-operations
>     that dispatch to ange-ftp:
> 
> It doesn't seem like a terribly important case to worry about.

For users of ido or icomplete as well as ange-ftp (or tramp?),
it is definitely a nuisance; I believe that the number of users
affected by this from time to time is fairly high.

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

Re: while-no-input

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > However, it would cleaner if instead of generating a quit signal it
> > did a throw to a specified tag.
> 
> The reason I didn't do that is that it didn't seem necessary
> and that I didn't want the QUIT macro to grow, but I could introduce
> a new function `quit' that the QUIT macro could call and which would
> either call `Fsignal (Qquit, Qnil)' ot `Fthrow (...)'.

Richard Stallman <rms@gnu.org> writes:

> That would be ok.

Stefan,

What happened with this feature?

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

Re: while-no-input

[Stefan Monnier]

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> 
> > > However, it would cleaner if instead of generating a quit signal it
> > > did a throw to a specified tag.
> > 
> > The reason I didn't do that is that it didn't seem necessary
> > and that I didn't want the QUIT macro to grow, but I could introduce
> > a new function `quit' that the QUIT macro could call and which would
> > either call `Fsignal (Qquit, Qnil)' ot `Fthrow (...)'.
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > That would be ok.
> 
> Stefan,
> 
> What happened with this feature?

Backburner.  Because I have other things to do for now and also because,
to tell you the truth, I'm not really psyched at the idea of using `throw'
instead of (signal 'quit <value>): after all this quit-on-input is really
a variant of `quit' and not something of a different nature.
Proof is that it should (and does) obey inhibit-quit.


	Stefan

Re: while-no-input

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> > 
> > > > However, it would cleaner if instead of generating a quit signal it
> > > > did a throw to a specified tag.
> > > 
> > > The reason I didn't do that is that it didn't seem necessary
> > > and that I didn't want the QUIT macro to grow, but I could introduce
> > > a new function `quit' that the QUIT macro could call and which would
> > > either call `Fsignal (Qquit, Qnil)' ot `Fthrow (...)'.
> > 
> > Richard Stallman <rms@gnu.org> writes:
> > 
> > > That would be ok.
> > 
> > Stefan,
> > 
> > What happened with this feature?
> 
> Backburner.  Because I have other things to do for now and also because,
> to tell you the truth, I'm not really psyched at the idea of using `throw'
> instead of (signal 'quit <value>): after all this quit-on-input is really
> a variant of `quit' and not something of a different nature.
> Proof is that it should (and does) obey inhibit-quit.

IIRC, RMS said that using signal like that was very unclean and using throw
would be cleaner.

But I tend to agree with you that just using signal would be both
simpler and more correct (obeying inhibit-quit), and I really don't
see why using throw [making the implementation more trickly] can
be said to be (much) cleaner than your original approach!

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

Re: while-no-input

[Richard Stallman]

    IIRC, RMS said that using signal like that was very unclean and using throw
    would be cleaner.

That is the first thing I said.  Afterwards I agreed to a modified
version of the change which avoids the ugliness at the Lisp level.

Re: while-no-input

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     IIRC, RMS said that using signal like that was very unclean and using throw
>     would be cleaner.
> 
> That is the first thing I said.  Afterwards I agreed to a modified
> version of the change which avoids the ugliness at the Lisp level.

True, but as I read Stefan's comments, removing the ugliness at the
Lisp level comes at the expense of increased ugliness and decreased
functional correctness at the C level.

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

Re: while-no-input

[Stefan Monnier]

>     IIRC, RMS said that using signal like that was very unclean and using
>     throw would be cleaner.
> 
> That is the first thing I said.  Afterwards I agreed to a modified
> version of the change which avoids the ugliness at the Lisp level.

I don't understand what you're referring to.
Are you saying that you did agree to a version that was not using `throw' ?
What ugliness at the Lisp level ?

I still have no idea what you mean by "ugly" in reference to my patch.
All it does is allow you to make normal keystrokes generate a quit event
and it also allows you to check which kind of quit event is generated
so you can tell the difference between a C-g quit and an any-key quit.

Using throw for such any-key quit sounds just plain wrong to me since
it is very much a `quit' like any other, that obeys inhibit-quit and
that aborts the current execution.

As I said, I'd probably settle for `throw' because I care more about
having the feature at all than about implementing it right (from my
point of view), but if I have to settle for `throw', it'll take me much
more time to get the patch ready/tested/installed, so someone else
might want to do it before me.


	Stefan

Re: while-no-input

[Richard Stallman]

    I don't understand what you're referring to.
    Are you saying that you did agree to a version that was not using `throw' ?

I agreed to the version using `throw'.  That is what I was referring to.

Re: while-no-input

[Richard Stallman]

    True, but as I read Stefan's comments, removing the ugliness at the
    Lisp level comes at the expense of increased ugliness and decreased
    functional correctness at the C level.

I don't think so.

Re: while-no-input

[Stefan Monnier]

Kim said:
>     IIRC, RMS said that using signal like that was very unclean and
>     using throw would be cleaner.

rms@gnu.org said:
> That is the first thing I said.  Afterwards I agreed to a modified
> version of the change which avoids the ugliness at the Lisp level. 

I then said:
>     I don't understand what you're referring to.
>     Are you saying that you did agree to a version that was not using `throw' ?

To which you now reply:
> I agreed to the version using `throw'.  That is what I was referring to.

Could you explain what is unclean about using `signal' ?
Currently, the only non-local exit that ever happens "asynchronously"
is the quit signal and it's also the only thing that obeys the
inhibit-quit flag.  The feature I'd like to introduce is also
an asynchonous non-local exit and should also obey the inhibit-quit
flag, so it seems eminently natural to use a quit signal as well.

The fact that the implementation is easier this way is just
reflects the fact that it is the "right" approach.


	Stefan

Re: while-no-input

[Richard Stallman]

    Could you explain what is unclean about using `signal' ?

I already did.  Error handling primitives should not be used for
normal occurrences that are not errors.

I don't have time for more discussion of this--sorry.

Re: while-no-input

[Stefan Monnier]

>     Could you explain what is unclean about using `signal' ?
> 
> I already did.  Error handling primitives should not be used for
> normal occurrences that are not errors.

Huh?  Than what about C-g ?
Doesn't look like an error to me any more than "hit any key to abort" does.


	Stefan

Re: while-no-input

[Richard Stallman]

C-g is pretty much like an error even if not exactly.
Quitting is not an anomaly, but it is not normal.
The arrival of more input is normal.

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.

last try (was: while-no-input)

[Stefan Monnier]

> C-g is pretty much like an error even if not exactly.
> Quitting is not an anomaly, but it is not normal.
> The arrival of more input is normal.

Not while you're inside `while-no-input'.  In the cases where I want
to use it, the arrival of user input is definitely not normal:
the code within while-no-input should normally run to completion
before the user hits a key.
And the code run inside `while-no-input' (typically tramp or ange-ftp)
usually has no idea that it might be interrupted by some keyboard input,
so such an occurrence is (for the running code) definitely not normal.

> 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 will probably not install it if that means having to use throw
for one case and signal for the other: too much work to uglify
a simple and clean design.

Another reason to use signal is that `throw' has the disadvantage
that you cannot catch the signal so any code you might want to run
"in case the execution is aborted" will need to use unwind-protect.
This might be the right tool in many cases, but not all.

Catch and throw work well when the two places where they occur are
conceptually linked and where the author has some control
over the code that is being unwound (i.e. the code between the catch and
the throw).  In the cases where I want to use while-no-input,
I have no control over this code (otherwise I could have added some
polling directly in that code).

If you don't want to spend time on it, please give a bit
of trust to those who are willing to spend the time.  I have spent
much more time thinking about the feature than implementing it,
so don't just assume that I want to use `signal' because the
implementation is simpler.  I also have spent much more time
thinking about it than you have, so I deserve a bit more credit.


	Stefan


PS: Kim, if you want this feature, you're probably better off
    doing the remaining work, because I'm fed up with this arguing.

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

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > C-g is pretty much like an error even if not exactly.
> > Quitting is not an anomaly, but it is not normal.
> > The arrival of more input is normal.
> 
> Not while you're inside `while-no-input'.  In the cases where I want
> to use it, the arrival of user input is definitely not normal:
> the code within while-no-input should normally run to completion
> before the user hits a key.
> And the code run inside `while-no-input' (typically tramp or ange-ftp)
> usually has no idea that it might be interrupted by some keyboard input,
> so such an occurrence is (for the running code) definitely not normal.

Exactly!!


> 
> > 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 agree with Stefan.

Richard, if you don't want to spend time thinking more about this,
please leave the decision to Stefan who has spend a lot of time on
this, and IMO has the right approach here.

> PS: Kim, if you want this feature, you're probably better off
>     doing the remaining work, because I'm fed up with this arguing.

I really think we need while-no-input, but while I can understand
Stefan's approach, I simply don't understand what Richard wants to be
done here, so I'm not the right person to ask to do that.

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

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

[Richard Stallman]

    > 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?

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

[Richard Stallman]

    Richard, if you don't want to spend time thinking more about this,

I thought about it enough to reach a conclusion.  I don't think there
is a need to think about more.

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

[Stefan Monnier]

>     > 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.
This is slightly dictatorial and very frustrating.


	Stefan

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

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> 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 <storm@cua.dk> http://www.cua.dk

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

[Richard Stallman]

    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.

It seemed to me that it would work.  Let's see.

    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.

Input should cause a nonlocal exit.  Signals and throw are both
nonlocal exits.

    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.

The proper way to do this is with unwind-protect, and that handles
both signals and throw the same way.

    In contrast, using throw/catch instead of Stefan's `annotated' quit
    signal _DOES_NOT_WORK_

You say this as if it were observed fact, but the reason you give

			   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!

is a theoretical supposition.  Have you tried it?

If the code was written properly, it should not care which kind of
nonlocal exit is used.

    - 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),

There is no evidence they need modification, only speculation.
And if it does need modification, the code probably was not
written in the recommended way, and the modification is probably
a good idea anyway.

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

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     In contrast, using throw/catch instead of Stefan's `annotated' quit
>     signal _DOES_NOT_WORK_
> 
> You say this as if it were observed fact, but the reason you give
> 
> 			   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!
> 
> is a theoretical supposition.  Have you tried it?

No, but I did look (briefly) at the relevant code.

I looked at ange-ftp and it does indeed use unwind-protect in many
places, but it also has this code:
 (condition-case ... (quit (delete-procss ...))).

From this I assumed that ange-ftp needed to be able to catch the quit
signal to properly clean-up connections.  However, looking at the code
again, I must admit that I'm less sure now, whether going through that
part of the code is really a good idea in case of user input!  Only
way to find out is to try it I guess...

I also looked at tramp and it has neither unwind-protects, nor
(condition-case ... quit ...), so I assumed that was quit-safe
[whatever that is ...].  
Maybe it works with both signal and throw -- maybe with neiter.

> 
> If the code was written properly, it should not care which kind of
> nonlocal exit is used.

I see.

> 
>     - 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),
> 
> There is no evidence they need modification, only speculation.
> And if it does need modification, the code probably was not
> written in the recommended way, and the modification is probably
> a good idea anyway.

Ok.  Maybe I'll give it a try then...

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

Re: last try

[Kai Großjohann]

storm@cua.dk (Kim F. Storm) writes:

> I also looked at tramp and it has neither unwind-protects, nor
> (condition-case ... quit ...), so I assumed that was quit-safe
> [whatever that is ...].  
> Maybe it works with both signal and throw -- maybe with neiter.

Tramp does not try to deal with this issue at all: if you hit C-g
while the process buffer is half-setup, then Tramp will happily use
the buffer after this.  Of course, this is bad.

I'm willing to do whatever seems to be useful.  Can anyone tell me
what Tramp should do regarding nonlocal exits?

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

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

[Richard Stallman]

    I looked at ange-ftp and it does indeed use unwind-protect in many
    places, but it also has this code:
     (condition-case ... (quit (delete-procss ...))).

I think you mean this code:

      (quit
       ;; If the user does quit out of this,
       ;; kill the process.  That stops any transfer in progress.
       ;; The next operation will open a new ftp connection.
       (delete-process proc)
       (signal 'quit nil)))))

This code was clearly meant to respond to C-g in particular, and I
think this code should NOT respond to arrival of input even if the
operation is inside of while-no-input.  So I think this instance
supports my feeling that this should not use the `quit' signal.

Using part of the quit mechanism in the C code is a convenient way to
implement while-no-input, but conceptually it is a separate feature
with nothing to do with quitting.

Re: last try

[Richard Stallman]

    I'm willing to do whatever seems to be useful.  Can anyone tell me
    what Tramp should do regarding nonlocal exits?

Generally speaking, it should use unwind-protect to clean up the
state so as to make the state regular again.

Precisely when and how that should be done is something only a person
familiar with the details of Tramp can say.