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

[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

[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

[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]

"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

[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]

>     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

[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]

    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)

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

[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

[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.

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

AW: vc-state always calls heuristic function

[klaus.berndl]

[-- Attachment #1.1: Type: text/plain, Size: 2663 bytes --]

sorry for sending this again - but until now i got
no answer to my question about the current state of
while-no-inmput - see below - maybe you have forgotten to
answer... ;-)

Klaus


-----Ursprüngliche Nachricht-----
Von: emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org im Auftrag von klaus.berndl@sdm.de
Gesendet: Mi 24.11.2004 15:44
An: monnier@iro.umontreal.ca
Cc: emacs-devel@gnu.org
Betreff: RE: vc-state always calls heuristic function
 
Stefan Monnier wrote:
>> and between each pass of the loop it is interruptable..well, but of
>> course there remains the problem - how to interrupt if one pass
>> takes long 
>> time...
> 
> Google for `while-no-input'.

Done - after reading the whole thread i can say: I agree at 100% with you and Kim.
Such a macro would be very important especially for a program like Emacs which
has still not thread-feature like Java, C++ et. al. IMHO this is one of the
most important any annoying lacks of emacs-lisp and for programmers...
And i agree with Kim that especially people working with remote-paths and
packages which makes this completely transparent (like tramp, ange-ftp and efs)
would profite a lot from such a macro like while-no-input - 

The current discussion how to enable tools like ECB to display some state-value
for files (as the VC-state-values) where the computation could be expensive
is IMHO a good example to demonstrate the need of such feature - so we have no
threads avaliable in emacs-lisp to perform such expensive tasks in the background
without blocking the user of Emacs but we could at least offer the users of
such tools a way how to easily (hitting C-g is not acceptable) interrupt also
"atomic" calls as call of call-process etc...

Well, Stefan - this thread was discussed in 2002 - what is current state of
this while-no-input???

>> Hmm, now i'm confused... ECB needs a function how to get the
>> VC-state. Well, the user can customize which function ECB should
>> use.  But if he should 
>> not use `vc-recompute-state' how he should get fresh-but-slow state??
> 
> Oh, you're right I got confused: vc-cvs-heuristic-state doesn't pay
> attention to vc-cvs-stay-local.  Hmmm....
> I guess VC could/should provide a function like vc-recompute-state or
> vc-check-for-updates.  Currently this operation is only provided as
> part of vc-next-action, but it might be nice to decouple the two.

Yes, see my discussion with Andre about this...

Klaus

> 
> 
>         Stefan



_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel


[-- Attachment #1.2: Type: text/html, Size: 3523 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: AW: vc-state always calls heuristic function

[Kim F. Storm]

Current state is that RMS rejected Stefan's implementation of while-no-input.

No further progress was made, as Stefan didn't want to pursue the
issue further and I didn't quite understand how RMS wanted to
implement it using a signal.

Too bad!!   It would be a very nice feature to have!



<klaus.berndl@sdm.de> writes:

> sorry for sending this again - but until now i got
> no answer to my question about the current state of
> while-no-inmput - see below - maybe you have forgotten to
> answer... ;-)
>
> Klaus
>
>
> -----Ursprüngliche Nachricht-----
> Von: emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org im Auftrag von klaus.berndl@sdm.de
> Gesendet: Mi 24.11.2004 15:44
> An: monnier@iro.umontreal.ca
> Cc: emacs-devel@gnu.org
> Betreff: RE: vc-state always calls heuristic function
>  
> Stefan Monnier wrote:
>>> and between each pass of the loop it is interruptable..well, but of
>>> course there remains the problem - how to interrupt if one pass
>>> takes long 
>>> time...
>> 
>> Google for `while-no-input'.
>
> Done - after reading the whole thread i can say: I agree at 100% with you and Kim.
> Such a macro would be very important especially for a program like Emacs which
> has still not thread-feature like Java, C++ et. al. IMHO this is one of the
> most important any annoying lacks of emacs-lisp and for programmers...
> And i agree with Kim that especially people working with remote-paths and
> packages which makes this completely transparent (like tramp, ange-ftp and efs)
> would profite a lot from such a macro like while-no-input - 
>
> The current discussion how to enable tools like ECB to display some state-value
> for files (as the VC-state-values) where the computation could be expensive
> is IMHO a good example to demonstrate the need of such feature - so we have no
> threads avaliable in emacs-lisp to perform such expensive tasks in the background
> without blocking the user of Emacs but we could at least offer the users of
> such tools a way how to easily (hitting C-g is not acceptable) interrupt also
> "atomic" calls as call of call-process etc...
>
> Well, Stefan - this thread was discussed in 2002 - what is current state of
> this while-no-input???
>
>>> Hmm, now i'm confused... ECB needs a function how to get the
>>> VC-state. Well, the user can customize which function ECB should
>>> use.  But if he should 
>>> not use `vc-recompute-state' how he should get fresh-but-slow state??
>> 
>> Oh, you're right I got confused: vc-cvs-heuristic-state doesn't pay
>> attention to vc-cvs-stay-local.  Hmmm....
>> I guess VC could/should provide a function like vc-recompute-state or
>> vc-check-for-updates.  Currently this operation is only provided as
>> part of vc-next-action, but it might be nice to decouple the two.
>
> Yes, see my discussion with Andre about this...
>
> Klaus
>
>> 
>> 
>>         Stefan
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

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

while-no-input

[Richard Stallman]

    Current state is that RMS rejected Stefan's implementation of while-no-input.

    No further progress was made, as Stefan didn't want to pursue the
    issue further and I didn't quite understand how RMS wanted to
    implement it using a signal.

I don't remember the discussion, but if you tell me what month it was,
I can search for the messages.

Re: while-no-input

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Current state is that RMS rejected Stefan's implementation of while-no-input.
>
>     No further progress was made, as Stefan didn't want to pursue the
>     issue further and I didn't quite understand how RMS wanted to
>     implement it using a signal.
>
> I don't remember the discussion, but if you tell me what month it was,
> I can search for the messages.

October/November 2002


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

Re: while-no-input

[Richard Stallman]

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?

Re: while-no-input

[Stefan Monnier]

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

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'.


        Stefan

Re: while-no-input

[Richard Stallman]

    > 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

I am not sure about that point, but the issue at hand is how to do the
nonlocal exit.  If while-no-input's implementation looks at
inhibit-quit, that is orthogonal to how do to the nonlocal exit.  So
let me make my statement more precise:

The only thing programs do to control quitting is to bind inhibit-quit
on and off.  Since inhibit-quit has no effect on what either Fsignal
or Fthrow does when it is called, using Fthrow instead of Fsignal is
entirely orthogonal to anything user programs do to control quitting.

    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.

The setting of Vquit_flag is asynchronous, but I don't see that
that relates to the issue.  Quitting itself can be done asynchronously
in a few primitives, but usually it occurs synchronously in a place
that checks for it and does QUIT.

The operational difference between signal and throw is that the former
is caught by `condition-case' while the latter is caught by `catch'.
So the way to decide the issue is based on whether `condition-case'
ought to catch this.  If the definition of with-no-input is that
it alone catches this, then it has to use `catch'.

So here's my simpler proposal for how to implement this.


(defmacro while-no-input (&rest body)
  "Execute BODY only as long as there's no pending input.
If input arrives, that ends the execution of BODY."
  (declare (debug t) (indent 0))
  (let ((catch-sym (make-symbol "input")))
    `(with-local-quit
       (catch ',catch-sym
	 (let ((throw-on-input ',catch-sym))
	   (when (sit-for 0 0 t)
	     ,@body))))))

#define QUIT						\
  do {							\
    if (!NILP (Vquit_flag) && NILP (Vinhibit_quit))	\
      {							\
        Lisp_Object flag = Vquit_flag;			\
	Vquit_flag = Qnil;				\
	if (EQ (Vthrow_on_input, flag))			\
	  Fthrow (Vthrow_on_input, Qnil);		\
	Fsignal (Qquit, Qnil);				\
      }							\
    else if (interrupt_input_pending)			\
      handle_async_input ();				\
  } while (0)
    



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 Vthrow_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 (Vthrow_on_input)
+      && event->kind != FOCUS_IN_EVENT
+      && event->kind != HELP_EVENT
+      && event->kind != DEICONIFY_EVENT)
+    Vquit_flag = Vthrow_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 ("throw-on-input", &Vthrow_on_input,
+	       doc: /* If non-nil, any keyboard input throws to this symbol.
+The value of that variable is passed to `quit-flag' and later causes a
+peculiar kind of quitting.  */);
+  Vthrow_on_input = Qnil;
 }
 
 void

Re: while-no-input

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> So here's my simpler proposal for how to implement this.

I tried it -- but I don't have SYNC_INPUT defined, so I used this:

#define QUIT						\
  do {							\
    if (!NILP (Vquit_flag) && NILP (Vinhibit_quit))	\
      {							\
        Lisp_Object flag = Vquit_flag;			\
	Vquit_flag = Qnil;				\
	if (EQ (Vthrow_on_input, flag))			\
	  Fthrow (Vthrow_on_input, Qnil);		\
	Fsignal (Qquit, Qnil);				\
      }							\
  } while (0)


I then ran this code (in my normal emacs with cua-mode enabled):

(while-no-input
  (while t
    (prin1 "x")
    (sit-for 0)))

and hit space after a few seconds.  Got a crash:


Breakpoint 1, abort () at emacs.c:442

(gdb) xbacktrace
"cua--post-command-handler"
"run-hooks"
(gdb) bt
#0  abort () at emacs.c:442
#1  0x08182ae9 in Feval (form=140121845) at eval.c:2015
#2  0x081819e0 in Fcondition_case (args=145132605) at eval.c:1329
#3  0x081b7204 in Fbyte_code (bytestr=144710763, vector=144806556, maxdepth=24) at bytecode.c:864
#4  0x08184383 in funcall_lambda (fun=144661804, nargs=0, arg_vector=0xbfffd608) at eval.c:2959
#5  0x08183dcb in Ffuncall (nargs=1, args=0xbfffd604) at eval.c:2820
#6  0x081836c8 in run_hook_with_args (nargs=1, args=0xbfffd604, cond=to_completion) at eval.c:2440
#7  0x081834bc in Frun_hooks (nargs=1, args=0xbfffd6d4) at eval.c:2308
#8  0x08183b46 in Ffuncall (nargs=2, args=0xbfffd6d0) at eval.c:2753
#9  0x0818386b in call1 (fn=137798905, arg1=137754665) at eval.c:2566
#10 0x0810cf01 in safe_run_hooks_1 (hook=0) at keyboard.c:2034
#11 0x08181b06 in internal_condition_case (bfun=0x810cee7 <safe_run_hooks_1>, handlers=137698537, hfun=0x810cf06 <safe_run_hooks_error>) at eval.c:1382
#12 0x0810cf9c in safe_run_hooks (hook=137754665) at keyboard.c:2062
#13 0x0810c25b in command_loop_1 () at keyboard.c:1801
#14 0x08181b06 in internal_condition_case (bfun=0x810adbb <command_loop_1>, handlers=137764305, hfun=0x810a900 <cmd_error>) at eval.c:1382
#15 0x0810ac33 in command_loop_2 () at keyboard.c:1309
#16 0x081815cc in internal_catch (tag=137756753, func=0x810ac14 <command_loop_2>, arg=137698489) at eval.c:1143
#17 0x0810abe6 in command_loop () at keyboard.c:1288
#18 0x0810a67f in recursive_edit_1 () at keyboard.c:981
#19 0x0810a7c0 in Frecursive_edit () at keyboard.c:1042
#20 0x0810911b in main (argc=3, argv=0xbfffdf04) at emacs.c:1742
#21 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) p handling_signal
$1 = 1
(gdb) p interrupt_input_blocked
$2 = 0
(gdb) 

Seems that we can break out of XTread_socket without restoring
handling_signal.

I don't know if it is sufficient to unwind protect it.


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

RE: while-no-input

[klaus.berndl]

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,
wouldn't it?

So i would do

(while-no-input ....
  (unwind-protect
  ;; 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

[Stefan Monnier]

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

About what?

> 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

I never said otherwise, did I?


        Stefan

RE: while-no-input

[klaus.berndl]

Stefan Monnier wrote:
>>> 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??
> 
> About what?

about "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)"... but it seems that i have
misunderstood your latest posting....

> 
>> 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 
> 
> I never said otherwise, did I?
> 
> 
>         Stefan