zsh exits after delete-char-or-list and two ^Cs

zsh exits after delete-char-or-list and two ^Cs

[Danek Duvall]

This happens with 4.0.6, 4.2.0 and 4.2.1, the first two on Linux, the
latter on Solaris.  If I use delete-char-or-list, then hit control-C twice,
the first time cancels the command-line where I hit ^D, and the second one
exits the shell.

This happens both with my normal config and running zsh -f.  With the
latter I can get the shell to exit (after using delete-char-or-list) by
hitting control-A a few times, then diddling around with the cursor keys
and typing a bit (though I can't find a consisten way of reproducing this).

Note that the shell simply exits, it doesn't crash.

Has this been brought up before?

Thanks,
Danek

Re: zsh exits after delete-char-or-list and two ^Cs

[Bart Schaefer]

On Wed, 25 Aug 2004, Danek Duvall wrote:

> This happens with 4.0.6, 4.2.0 and 4.2.1, the first two on Linux, the 
> latter on Solaris.  If I use delete-char-or-list, then hit control-C 
> twice, the first time cancels the command-line where I hit ^D, and the 
> second one exits the shell.

Looks like the interrupt handler isn't getting reset after the first 
ctrl-C.  I don't yet know why not, but this means that the default SIGINT
handler is called on the second ^C, which of course ends the process.

There also appears to be a bug in 4.2.x with "zle -I" and "zle -R".  This 
should work:

	TRAPINT() { zle -I && zle send-break }

because "zle -I" is supposed to return zero only when zle is active. 
However, I get:

	TRAPINT:zle: widgets can only be called when ZLE is active

In any case there are numerous workarounds involving trapping ^C or using 
"stty" to disable interrupt ... but they all have drawbacks.

Re: zsh exits after delete-char-or-list and two ^Cs

[Peter Stephenson]

Danek Duvall wrote:
> This happens with 4.0.6, 4.2.0 and 4.2.1, the first two on Linux, the
> latter on Solaris.  If I use delete-char-or-list, then hit control-C twice,
> the first time cancels the command-line where I hit ^D, and the second one
> exits the shell.

Obviously if I tried to look at this today after my holiday it would
just get me all frustrated.  So that would be a bad idea.

Here's a patch.  The problem is that there's a special test to see if
there was an EOF character (which must be ^D for the bug to turn up in
this particular form) at the start of the line.  This test was
erroneously triggered on the second ^C as the input character hadn't
changed from the ^D used to list completion.  The first ^C didn't
trigger it because the line hadn't yet been emptied.  The functions
don't pass back the state properly, so it's difficult to check what
actually happened (i.e. EOF or interrupt); maybe it can be done better
than this.

Note that errflag isn't set at the point of the patch if there was a ^C.
This seems to be deliberate; see the handling of EINTR in getkey().  I
think it's also to do with the lack of distinction between an
interruption and an EOF---in loop(), we exit the command loop, and
hence the shell, if we get an end-of-input token and errflag is *not* set.

I thought about resetting lastchar at the start of each line.  However,
I think there are cases where that doesn't work.

Index: Src/Zle/zle_main.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_main.c,v
retrieving revision 1.49
diff -u -r1.49 zle_main.c
--- Src/Zle/zle_main.c	13 Jul 2004 09:41:37 -0000	1.49
+++ Src/Zle/zle_main.c	1 Sep 2004 17:15:15 -0000
@@ -687,12 +687,19 @@
 	reselectkeymap();
 	selectlocalmap(NULL);
 	bindk = getkeycmd();
-	if (!ll && isfirstln && !(zlereadflags & ZLRF_IGNOREEOF) &&
-	    lastchar == eofchar) {
-	    eofsent = 1;
-	    break;
-	}
 	if (bindk) {
+	    if (!ll && isfirstln && !(zlereadflags & ZLRF_IGNOREEOF) &&
+		lastchar == eofchar) {
+		/*
+		 * Slight hack: this relies on getkeycmd returning
+		 * a value for the EOF character.  However,
+		 * undefined-key is fine.  That's necessary because
+		 * otherwise we can't distinguish this case from
+		 * a ^C.
+		 */
+		eofsent = 1;
+		break;
+	    }
 	    if (execzlefunc(bindk, zlenoargs))
 		handlefeep(zlenoargs);
 	    handleprefixes();

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: zsh exits after delete-char-or-list and two ^Cs

[Peter Stephenson]

Bart Schaefer wrote:
> There also appears to be a bug in 4.2.x with "zle -I" and "zle -R".  This 
> should work:
> 
> 	TRAPINT() { zle -I && zle send-break }
> 
> because "zle -I" is supposed to return zero only when zle is active. 
> However, I get:
> 
> 	TRAPINT:zle: widgets can only be called when ZLE is active

The first problem is that zle -I doesn't have the same test as zle
<widget>.  It's reasonable that it should.

The second problem is that the test currently includes the function
context.  In this case, we've been called from a trap.  I'm not
convinced this test is necessary; I think it should work as long as
zleactive is set, so that we are in a nested context.  So I've removed
that test.  If there are cases where this is problematic, they should be
fixed up separately.

Actually, the context could be SFC_COMPLETE or SFC_CWIDGET for old- and
new-style completion functions, in which case we don't want to allow
normal zle widgets.  However, I think in this case the existing tests
for incompctlfunc and incompfunc are good enough.  A simple test seems
to indicate they are.

It still doesn't work as you expect, since you get the normal effect of
^C as well as the effect of the send-break.  I'm not convinced that's a
bug, yet.

Index: Doc/Zsh/zle.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/zle.yo,v
retrieving revision 1.39
diff -u -r1.39 zle.yo
--- Doc/Zsh/zle.yo	29 Jul 2004 14:22:21 -0000	1.39
+++ Doc/Zsh/zle.yo	1 Sep 2004 18:02:00 -0000
@@ -507,7 +507,8 @@
 
 The status is zero if zle is active and the current zle display has
 been invalidated (even if this was by a previous call to `tt(zle -I)'),
-else one.
+else one.  More precisely, the status is zero if zle is currently in a
+usable state, i.e. a zle widget can be called immediately.
 )
 item(var(widget) tt([ -n) var(num) tt(]) tt([ -N ]) var(args) ...)(
 Invoke the specified widget.  This can only be done when ZLE is
Index: Src/Zle/zle_thingy.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_thingy.c,v
retrieving revision 1.13
diff -u -r1.13 zle_thingy.c
--- Src/Zle/zle_thingy.c	2 Jun 2004 22:15:02 -0000	1.13
+++ Src/Zle/zle_thingy.c	1 Sep 2004 18:02:02 -0000
@@ -619,6 +619,23 @@
 
 /**/
 static int
+zle_usable()
+{
+    return zleactive && !incompctlfunc && !incompfunc
+#if 0
+	/*
+	 * PWS experiment: commenting this out allows zle widgets
+	 * in signals, hooks etc.  I'm not sure if this has a down side;
+	 * it ought to be that zleactive is good enough to test whether
+	 * widgets are callable.
+	 */
+	&& sfcontext == SFC_WIDGET
+#endif
+	   ;
+}
+
+/**/
+static int
 bin_zle_call(char *name, char **args, UNUSED(Options ops), UNUSED(char func))
 {
     Thingy t;
@@ -629,10 +646,9 @@
     if (!wname) {
 	if (saveflag)
 	    zmod = modsave;
-	return (!zleactive || incompctlfunc || incompfunc ||
-		sfcontext != SFC_WIDGET);
+	return !zle_usable();
     }
-    if(!zleactive || incompctlfunc || incompfunc || sfcontext != SFC_WIDGET) {
+    if(!zle_usable()) {
 	zwarnnam(name, "widgets can only be called when ZLE is active",
 	    NULL, 0);
 	return 1;
@@ -685,7 +701,7 @@
 static int
 bin_zle_invalidate(UNUSED(char *name), UNUSED(char **args), UNUSED(Options ops), UNUSED(char func))
 {
-    if (zleactive) {
+    if (zle_usable()) {
 	if (!trashedzle)
 	    trashzle();
 	return 0;

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: zsh exits after delete-char-or-list and two ^Cs

[Bart Schaefer]

On Wed, 1 Sep 2004, Peter Stephenson wrote:

>  bin_zle_invalidate(UNUSED(char *name), UNUSED(char **args), UNUSED(Options ops), UNUSED(char func))
>  {
> +    if (zle_usable()) {
>  	if (!trashedzle)
>  	    trashzle();
>  	return 0;

The effect of this is going to be that "zle -I" has no effect when called
from completion widgets, where previously it could.  Is that really the
intent?

I'd think you wanted something more like:

  if (zleactive) {
      if (!trashedzle)
          trashzle();
      return zle_usable()? 0 : 1;
  }

(Though perhaps not precisely that either.)

Re: zsh exits after delete-char-or-list and two ^Cs

[Peter Stephenson]

Bart Schaefer wrote:
> The effect of this is going to be that "zle -I" has no effect when called
> from completion widgets, where previously it could.  Is that really the
> intent?
>
> I'd think you wanted something more like:
> 
>   if (zleactive) {
>       if (!trashedzle)
>           trashzle();
>       return zle_usable()? 0 : 1;
>   }
> 
> (Though perhaps not precisely that either.)

Well, that would do, if suitably documented.

It looks like it would be more sensible to have the test for whether a
zle widget is callable separate from the return status for zle -I.
However, it's a bit late now.

Index: Doc/Zsh/zle.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/zle.yo,v
retrieving revision 1.39
diff -u -r1.39 zle.yo
--- Doc/Zsh/zle.yo	29 Jul 2004 14:22:21 -0000	1.39
+++ Doc/Zsh/zle.yo	2 Sep 2004 09:15:35 -0000
@@ -505,9 +505,12 @@
 Note that there are normally better ways of manipulating the display from
 within zle widgets; see, for example, `tt(zle -R)' above.
 
-The status is zero if zle is active and the current zle display has
-been invalidated (even if this was by a previous call to `tt(zle -I)'),
-else one.
+The returned status is zero if a zle widget can be called immediately.
+Note this is independent of whether the display has been invalidated.
+For example, if a completion widget is active a zle widget cannot be used
+and the status is one even if the display was invalidated; on the other
+hand, the status may be zero if the display was invalidated by a previous
+call to `tt(zle -I)'.
 )
 item(var(widget) tt([ -n) var(num) tt(]) tt([ -N ]) var(args) ...)(
 Invoke the specified widget.  This can only be done when ZLE is
Index: Src/Zle/zle_thingy.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_thingy.c,v
retrieving revision 1.13
diff -u -r1.13 zle_thingy.c
--- Src/Zle/zle_thingy.c	2 Jun 2004 22:15:02 -0000	1.13
+++ Src/Zle/zle_thingy.c	2 Sep 2004 09:15:36 -0000
@@ -619,6 +619,23 @@
 
 /**/
 static int
+zle_usable()
+{
+    return zleactive && !incompctlfunc && !incompfunc
+#if 0
+	/*
+	 * PWS experiment: commenting this out allows zle widgets
+	 * in signals, hooks etc.  I'm not sure if this has a down side;
+	 * it ought to be that zleactive is good enough to test whether
+	 * widgets are callable.
+	 */
+	&& sfcontext == SFC_WIDGET
+#endif
+	   ;
+}
+
+/**/
+static int
 bin_zle_call(char *name, char **args, UNUSED(Options ops), UNUSED(char func))
 {
     Thingy t;
@@ -629,10 +646,9 @@
     if (!wname) {
 	if (saveflag)
 	    zmod = modsave;
-	return (!zleactive || incompctlfunc || incompfunc ||
-		sfcontext != SFC_WIDGET);
+	return !zle_usable();
     }
-    if(!zleactive || incompctlfunc || incompfunc || sfcontext != SFC_WIDGET) {
+    if(!zle_usable()) {
 	zwarnnam(name, "widgets can only be called when ZLE is active",
 	    NULL, 0);
 	return 1;
@@ -685,10 +701,15 @@
 static int
 bin_zle_invalidate(UNUSED(char *name), UNUSED(char **args), UNUSED(Options ops), UNUSED(char func))
 {
+    /*
+     * Trash zle if trashable, but only indicate that zle is usable
+     * if it's possible to call a zle widget next.  This is not
+     * true if a completion widget is active.
+     */
     if (zleactive) {
 	if (!trashedzle)
 	    trashzle();
-	return 0;
+	return !zle_usable();
     } else
 	return 1;
 }

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: zsh exits after delete-char-or-list and two ^Cs

[Bart Schaefer]

On Thu, 2 Sep 2004, Peter Stephenson wrote:

> It looks like it would be more sensible to have the test for whether a
> zle widget is callable separate from the return status for zle -I.

What about zle -R ?

I think (but haven't applied it yet) that with this patch we have

  zle && echo "widgets callable"	# I'm least certain of this
  zle -I && echo "Display invalidated and widgets callable"
  zle -R && echo "Display refreshed and zle active"

Is that right?

This covers all bases, assuming it's harmless to call zle -R even when you 
don't really care whether the display is refreshed.  Unless one might need
to know that the display has been invalidated even when widgets are not
callable?  I'm having a hard time coming up with that.

> However, it's a bit late now.

Well, no, not really -- if in fact "zle" with no arguments does correctly 
mean "widgets callable", then "zle -I" could continue as "zle active".
Perhaps this was all a documentation problem to begin with.

Sorry to nit-pick, but:

> Index: Doc/Zsh/zle.yo
> ===================================================================
> +The returned status is zero if a zle widget can be called immediately.
> +Note this is independent of whether the display has been invalidated.
> +For example, if a completion widget is active a zle widget cannot be used
> +and the status is one even if the display was invalidated; on the other
> +hand, the status may be zero if the display was invalidated by a previous
> +call to `tt(zle -I)'.

Isn't it more accurate to say "the status may be nonzero even if the 
display was invalidated by a previous call"?  With the rest of the patch 
as it stands, the status is never zero when completion widgets are active, 
even when the display was previously invalidated -- but the above seems to 
imply that the status might be zero in that event.

Re: zsh exits after delete-char-or-list and two ^Cs

[Peter Stephenson]

(Oliver says the In-reply-to and References format should work better
like this.  Tell me if it doesn't.)

Bart Schaefer wrote:
> On Thu, 2 Sep 2004, Peter Stephenson wrote:
> 
> > It looks like it would be more sensible to have the test for whether a
> > zle widget is callable separate from the return status for zle -I.
> 
> What about zle -R ?
> 
> I think (but haven't applied it yet) that with this patch we have
> 
>   zle && echo "widgets callable"	# I'm least certain of this
>   zle -I && echo "Display invalidated and widgets callable"
>   zle -R && echo "Display refreshed and zle active"
> 
> Is that right?

Yes, noting that testing for `display invalidated' and `display
refreshed' doesn't form part of the return status (I think that's what
you mean but it's not clear from the output).

> This covers all bases, assuming it's harmless to call zle -R even when you 
> don't really care whether the display is refreshed.  Unless one might need
> to know that the display has been invalidated even when widgets are not
> callable?  I'm having a hard time coming up with that.

I agree, it's just a question of how much of a stickler you are for
having the return status reflecting `command did what I expected' rather
than `command did something and tested for something else'.  Unless
someone is using ERR_RETURN inside widgets (yuk!) I don't suppose this
is a problem.

> Sorry to nit-pick, but:
> 
> > Index: Doc/Zsh/zle.yo
> > ===================================================================
> > +The returned status is zero if a zle widget can be called immediately.
> > +Note this is independent of whether the display has been invalidated.
> > +For example, if a completion widget is active a zle widget cannot be used
> > +and the status is one even if the display was invalidated; on the other
> > +hand, the status may be zero if the display was invalidated by a previous
> > +call to `tt(zle -I)'.
> 
> Isn't it more accurate to say "the status may be nonzero even if the 
> display was invalidated by a previous call"?  With the rest of the patch 
> as it stands, the status is never zero when completion widgets are active, 
> even when the display was previously invalidated -- but the above seems to 
> imply that the status might be zero in that event.

Ah, I think I see: you're reading the two cases around the semicolon in
conjunction, while I meant them to be independent.  However, your
emendation doesn't get across quite the point I wanted, which is "if you
call zle -I and it returns zero, it may be that the display was
invalidated by a previous call rather than the current one".  Maybe
reversing the sense of the second case is better.  You might well say
"who cares", but I want to emphasis calling zle -I multiple times has no
bad effect.  Maybe the English for that is "calling zle -I multiple
times has no bad effects".

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: zsh exits after delete-char-or-list and two ^Cs

[Bart Schaefer]

On Fri, 3 Sep 2004, Peter Stephenson wrote:

> (Oliver says the In-reply-to and References format should work better
> like this.  Tell me if it doesn't.)

(Looks fine.  What are you using as a mail reader?)

> Bart Schaefer wrote:
> >   zle && echo "widgets callable"	# I'm least certain of this
> >   zle -I && echo "Display invalidated and widgets callable"
> >   zle -R && echo "Display refreshed and zle active"
> > 
> > Is that right?
> 
> Yes, noting that testing for `display invalidated' and `display
> refreshed' doesn't form part of the return status (I think that's what
> you mean but it's not clear from the output).

Hmm.  OK, that's not so good, because it breaks "zle -I || ..." in the 
case where you want to know whether the display was NOT invalidated.
(Maybe there's never a reason to care about that, but ...)

> I agree, it's just a question of how much of a stickler you are for
> having the return status reflecting `command did what I expected' rather
> than `command did something and tested for something else'.

I'm quite willing to have "zle -I" go back to testing for "invalidating
the display was a sensible thing to attempt" provided that "zle" (no args)
tests for "widgets callable", and that all of this is documented more
clearly.

> I want to emphasis calling zle -I multiple times has no bad effect.  
> Maybe the English for that is "calling zle -I multiple times has no bad 
> effects".

Yeah.

Re: zsh exits after delete-char-or-list and two ^Cs

[Peter Stephenson]

> On Fri, 3 Sep 2004, Peter Stephenson wrote:
> > Bart Schaefer wrote:
> > >   zle && echo "widgets callable"	# I'm least certain of this
> > >   zle -I && echo "Display invalidated and widgets callable"
> > >   zle -R && echo "Display refreshed and zle active"
> > > 
> > > Is that right?
> > 
> > Yes, noting that testing for `display invalidated' and `display
> > refreshed' doesn't form part of the return status (I think that's what
> > you mean but it's not clear from the output).
> 
> Hmm.  OK, that's not so good, because it breaks "zle -I || ..." in the 
> case where you want to know whether the display was NOT invalidated.
> (Maybe there's never a reason to care about that, but ...)

I don't think there is, in fact, but for the sake of logic it's probably
worth changing.  I've looked at the pattern of usage of zle -I in the
various functions I've got and I never test the return value at all:
either zle wasn't active, or it's been invalidated, and either are good
enough for me.  (I do, however, test [[ -o zle ]] beforehand to avoid
having to load it if it wasn't in use.)

It would require putting the test back to testing for zleactive.  That
means your original example wouldn't work, but as you say that's really
a problem with the documentation for when I feel fit enough to look at
the zle documentation again.

The display is refreshed if and only if zle is active on zle -R, so that
doesn't need changing.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: zsh exits after delete-char-or-list and two ^Cs

[Peter Stephenson]

This rearranges the status.  Most of this is just clarification.  I move
documentation for calling zle on its own to the top, since it was a bit
buried.

Index: Doc/Zsh/zle.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/zle.yo,v
retrieving revision 1.40
diff -u -r1.40 zle.yo
--- Doc/Zsh/zle.yo	2 Sep 2004 14:34:39 -0000	1.40
+++ Doc/Zsh/zle.yo	8 Sep 2004 14:20:18 -0000
@@ -312,6 +312,7 @@
 cindex(calling widgets)
 cindex(widgets, defining)
 cindex(defining widgets)
+xitem(tt(zle))
 xitem(tt(zle) tt(-l) [ tt(-L) | tt(-a) ] [ var(string) ... ])
 xitem(tt(zle) tt(-D) var(widget) ...)
 xitem(tt(zle) tt(-A) var(old-widget) var(new-widget))
@@ -323,10 +324,18 @@
 xitem(tt(zle) tt(-K) var(keymap))
 xitem(tt(zle) tt(-F) [ tt(-L) ] [ var(fd) [ var(handler) ] ])
 xitem(tt(zle) tt(-I))
-xitem(tt(zle) var(widget) tt([ -n) var(num) tt(]) tt([ -N ]) var(args) ...)
-item(tt(zle))(
+item(tt(zle) var(widget) tt([ -n) var(num) tt(]) tt([ -N ]) var(args) ...)(
 The tt(zle) builtin performs a number of different actions concerning
-ZLE.  Which operation it performs depends on its options:
+ZLE.
+
+With no options and no arguments, only the return status will be
+set.  It is zero if ZLE is currently active and widgets could be
+invoked using this builtin command and non-zero otherwise.
+Note that even if non-zero status is returned, zle may still be active as
+part of the completion system; this does not allow direct calls to ZLE
+widgets.
+
+Otherwise, which operation it performs depends on its options:
 
 startitem()
 item(tt(-l) [ tt(-L) | tt(-a) ])(
@@ -392,7 +401,9 @@
 This command can safely be called outside user defined widgets; if zle is
 active, the display will be refreshed, while if zle is not active, the
 command has no effect.  In this case there will usually be no other
-arguments.  The status is zero if zle was active, else one.
+arguments.
+
+The status is zero if zle was active, else one.
 )
 item(tt(-M) var(string))(
 As with the tt(-R) option, the var(string) will be displayed below the 
@@ -505,12 +516,10 @@
 Note that there are normally better ways of manipulating the display from
 within zle widgets; see, for example, `tt(zle -R)' above.
 
-The returned status is zero if a zle widget can be called immediately.
-Note this is independent of whether the display has been invalidated.
-For example, if a completion widget is active a zle widget cannot be used
-and the status is one even if the display was invalidated; on the other
-hand, the status may be zero if the display was invalidated by a previous
-call to `tt(zle -I)'.
+The returned status is zero if zle was invalidated, even though
+this may have been by a previous call to `tt(zle -I)' or by a system
+notification.  To test if a zle widget may be called at this point, execute
+tt(zle) with no arguments and examine the return status.
 )
 item(var(widget) tt([ -n) var(num) tt(]) tt([ -N ]) var(args) ...)(
 Invoke the specified widget.  This can only be done when ZLE is
@@ -540,10 +549,6 @@
 it should call the tt(beep) widget directly.
 )
 enditem()
-
-With no options and no arguments, only the return status will be
-set. It is zero if ZLE is currently active and widgets could be
-invoked using this builtin command and non-zero if ZLE is not active.
 )
 enditem()
 
Index: Src/Zle/zle_thingy.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_thingy.c,v
retrieving revision 1.14
diff -u -r1.14 zle_thingy.c
--- Src/Zle/zle_thingy.c	2 Sep 2004 14:34:39 -0000	1.14
+++ Src/Zle/zle_thingy.c	8 Sep 2004 14:20:21 -0000
@@ -709,7 +709,7 @@
     if (zleactive) {
 	if (!trashedzle)
 	    trashzle();
-	return !zle_usable();
+	return 0;
     } else
 	return 1;
 }

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************